Re: [Fwd: Re: 'with pixels' (was Re: Engines are started; ...)]

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>Not really.  The mess we're talking about here (the mapping from data
>values accessed a seris of 'using' specifiers to elements of 'struct
>coordinate' (x,y,z,ylow,...) is currently a two-part one: part one is that
>the number of specifiers changes the assignment from a position in the
>using spec sequence to struct elements (e.g. errorbars: 3 columns mean
>x:y:dy, 4 columns mean x:y:ylow:yhigh, i.e. the meaning of the third
>specifier depends on whether there's a forth one or not).  The *other*
>aspect of the mess is that users have to memorize the order of using spec
>for all plot styles.
>

Yes, I know.  That is somewhat of an inconvenience.

>>configuration inside a table.  That is, there is the enumeration for the 
>>PLOT_STYLE and one could build tables off of that.  
>>    
>>
>
>Or rather, I guess what we should consider is a re-organization of the
>entire way plot styles are handled.  The current 'enum with flags in'
>approach of defining plot style indices as magic numbers is of rather
>limited versatility, and more of a hack than a proper design.  
>
>Currently we have 9 switch() statements over the plot type, and about 90
>other comparisons of the plot_style field with particular types, scattered
>all across the 4 inner core modules (plot[23]d, graphics, graph3d) and
>several others.  I think this would all make a lot more sense if we
>collected at least all code governed by those switch()es, but possibly
>more, in one contiguous block of code *per plot style*.  I.e. all special
>code for handling the 'with yerrorbars' style should be in *one* place.
>

Better organization would be nice.  I thought more about what I wrote 
using lookup tables and concluded if one were to do all that work, maybe 
some other approaches would be even more worthwhile.  This is getting a 
ways ahead, but one idea might be to eliminate the unused columns of the 
style.  I can imagine a way to do it, but I think along the way you'd 
end up having to cast a pointer to the coordinate structure one is 
interested in.  That would make for ugly code.

Dan