Re: [boost] [Boost.Parameter] advice needed for Boost.svg_plot

From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2007-06-27 09:20:54

On 27/06/07, Jake Voytko <jakevoytko_at_[hidden]> wrote:
> Here's my case for why the benefits are compelling for plot_range(), if not
> other functions. Each different data point could potentially be styled many
> different ways. They could have their own shape, their own stroke color and
> fill color, their own size, 2d graphs could have line styling, line
> thickness, line color, whether or not there is a regression line, and
> whether or not the curve of the data is interpolated, to name just what I
> can think of off the top of my head.
>
> Either I make one monolithic function that takes in all of these arguments:
>
> plot_range(my_plot, data.begin(), data.end(), circle, blue, black, 12,
> dotted, 2, black, false, false);
>
> Or I create 5 or 6 plot_range() functions to take care of the combinations I
> feel people will need. It looks nice so far because I've been purposely
> picking and choosing what I implement in order to make it nice ;). The rest
> of the functions I may not need it as much (or at all.. it seems to work
> fine without named parameters), but I definitely need to come up with
> something better for plot_range, because otherwise each new feature I add to
> plot_range() will either make the number of plot_range() overloads jump up,
> or make it that much harder to understand what's going on.
>
It seems like with that much stuff for each point, it might be useful
to have a struct for representing a point style.  It seems plausible
to want to pass that kind of thing around, and nobody will want to
forward all those options manually, named parameters or not.

That way you get the non-Boost.Parameter way of faking named parameters free:
plot_range( my_plot, data.begin(), data.end(),
    point_style().set_shape(circle)
                 .set_fill(blue)
                 .set_outline(black) );
And you get the defaults for everything unspecified.  You also might
be able to get rid of most of the overloads and instead have functions
that return point_style objects, or have some implicit constructors
for the simple cases (like from a colour, to do the same thing as the
overload you use in the examples).

~ Scott McMurray