I'm skipping ahead a bit to address the API concerns below. Alan - sorry for skipping over your reply for the moment. I'll get to your longer questions as soon as I'm able.
On Thu, May 2, 2013 at 3:43 PM, Andrew Ross <andrewr...@users.sourceforge.net> wrote: > Alan, > > I think I broadly agree with all your comments below. My only concern with the > plcolorbar API is that it has now become a monstorous beast. It is certainly > the most complicated API call in plplot. Much of this functionality won't be > needed by most users. I wonder if there is a better way to pack all these > options into structure to prevent cluttering code for the majority of cases. > This might be tricky to port to some languages which don't have such concepts. > I agree with your assessment. I hate to say it but both plcolorbar and pllegend are bordering on unusable at this point in their raw C form given the staggering number of arguments required. I think that all of these arguments are useful but the quantity is troublesome. I got a mixed reaction from the developers when I presented the idea of creating a more 'modern' API structure for PLplot. Andrew, your suggestion here runs along those lines. I would like to break up these functions to take a struct or several as a means of simplifying their API. For example, information for each axis could be provided as a single value. An axis structure value could be created with a helper function. This same function could potentially be used to create axis definitions for any plot. If I'm going to take this approach - which again, I'd really like to do! - then I would also like this to be part of a general move toward this kind of API throughout PLplot. Otherwise these very useful functions would stick out strangely from everything else. All that said, this is probably post-5.10.0 work. For 5.10.0 I'd like to stick with the current large number of arguments approach. The new API structure would probably have a new naming scheme anyway. Maybe pl_* or plplot_*. > I agree const arguments for the string pointers would be wise. > There was a reason I didn't go that route for the string arguments initially but I don't remember what it was. If it doesn't break code then I'm fine with the change. Hez ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
