On 6/15/07, Paul A Bristow <pbristow@hetp.u-net.com> wrote:
svg_plot& operator<<(svg_plot& p,const triangle& t) { return p<<line(...)<<line(...)<<line(...); }
...
svg_plot my_plot; my_plot<<triangle(...);
perhaps you can expand on this?
1 What is the value in avoiding modifying the public interface? Looking towards standards?
Last night, I was playing around with the implications of what Joaquín said / looking through feature requests, and I came up with an example of a function that solves a request of yours (a way to save settings you would frequently use) with no extra work on the interface: //BEWARE! experimental syntax, and not an actual tested example. // 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: p << image_size (800, 600) << show_axis << x_axis_color( blue ) << y_axis_color( darkgray ) << x_axis_major_tick_color( gray) << y_axis_major_tick_color( darkgray ) << x_axis_minor_tick_color( gray ) << y_axis_minor_tick_color( gray ) << show_background_border << background_border_color ( darkgray ) << background_border_thickness( 5 ) << background_color ( lightblue ) // ... you get the point. This could go on for pages. break; } return p; } // in user_program.cpp int main() { svg_plot my_plot; my_plot << my_initial_style; // work } // end program As far as avoiding modifying the interface, it'll simply make the program less prone to bugs, it'll be less to test, it'll be less for future maintainers to worry about breaking regressions for, and most importantly, it's extensible. As long as you can reduce an operation to commands supported by the svg_plot or svg interface, you can implement it once and use it as many times as you want. 2 Can it not be done other ways? p.line(t1,t2).line(t2,t3).line(t3,t1)? Using the triangle example for the svg class, I don't think that there's any way using basic C++ syntax to do this within a function call. (I'm not familiar enough with template metaprogramming to make a statement to that effect) 3 Are the set and stream methods mutually exclusive? No, they can exist at the same time. There's no good reason a class couldn't support both. The only question I have is whether or not that would be good programming practice (to maintain the header, you'd have to make the same changes to the interface to both the set_ and << functions) 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. PS Opinions are clearly divided on this issue. Should we try to get more
views from elsewhere?
I'm open to anything. Do you have any ideas, or alternate locations we can go? Thank you for your time! Jake