// in user_header.hpp enum svg_user_customization { my_initial_style, ... };
svg_plot& operator<<(svg_plot& p, svg_user_customization val) { switch(val) { case my_initial_style:
[...] } }
// in user_program.cpp int main() { svg_plot my_plot; my_plot << my_initial_style;
// work }
// end program
Is there a raison to use an enumeration instead of a 'tag' type for selecting the implementation? (if I am not clear, an example follow) using a type would need to use () but can probably be more powerful. An example: Class MyStyle { Public: Explicit MyStyle(float BgClr):m_bg_clr(BgClr) {} Float get BgClr() {...} Protected: float m_bg_clr; }; Class AnotherStyle {}; svg_plot& operator<<(svg_plot& p, MyStyle val) { p << axis_on << color(val.getBgClr()) << ... } svg_plot& operator<<(svg_plot& p, AnotherStyle) { p << axis_off } Int main() { P << MyStyle(0.7) << plot(); P << AnotherStyle() << truc; MyStyle s1(0.2); P << s1 << somethings; }
2 Can it not be done other ways? p.line(t1,t2).line(t2,t3).line(t3,t1)?
We want the primitive (Triangle here) to be user defined, isn't it? We could have p.add<Triangle>(t1,t2,t3); or p.add(Triangle(t1,t2,t3)); or p.add<Triangle>(t1)(t2)(t3); but I don't really see the advantage over stream based interface.
3 Are the set and stream methods mutually exclusive? programming practice (to maintain the header, you'd have to make the same changes to the interface to both the set_ and << functions)
One can call the other but the argument type would need to be duplicated
4 Could this be used even if the set method was used for other parameters?
Yes. However, combining my answers for #1 and #3, I think it would be best to keep them all in the stream interface.
Personally, I found the streaming interface for adding object pretty good. But I like the setter interface better for customizing the svg_plot. But it isn't a very important choice in my eyes. -- Cédric Venet