Re: [boost] Progress of Boost.SVG_Plot

From: Jake Voytko (jakevoytko_at_[hidden])
Date: 2007-06-15 14:30:03

On 6/15/07, Paul A Bristow <pbristow_at_[hidden]> 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