On 2013-05-02 20:43+0100 Andrew Ross 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.
No question, both the pllegend and plcolorbar API's require a large (!) number of arguments in order to take advantage of the legend and colorbar features that we have implemented. Let me concentrate first on the pllegend case since that is the one I am more familiar with. As demonstrated in our C examples many of those arguments can be NULL depending on the options arguments. (And I think we should follow that up with some sanity checks in the pllegend routine such that if the options call for using one of those arrays, and the required array has a NULL address, then plwarn is called and the option turned off before the generation of the legend continues.) Anyhow, the NULL array argument possibilities already makes it easier for users to use the pllegend API from C, and I think we should follow that up for each language with function overloading by making some useful pllegend variants with much more limited arguments for the most useful common cases. I don't know quite how "packing options into structure" would simplify the C case that much, but if that turns out to be a good idea, then we can certainly stick with the present API for the other languages (i.e., by having the language interface code pack up what is needed at the C level) including overloaded function variants with more limited argument lists. For the plcolorbar case there are still two C API changes on the table; one from me on the types of the arguments which are an array of pointers to strings and one from Hez on extra functionality he would like to see incorporated. However, when that API does settle down, I think we should follow up the same way as done or proposed above for pllegend. That is, implement NULL array arguments that are sanity checked at the C level, and implement function overloading of the most useful type of limited argument calls to plcolorbar for other languages that support function overloading. > In terms of the extra functionality I'm happy to go along with Hez's > recommendation. He has developed this based on actual need so if he thinks it > is required it probably is. My colorbar research needs are currently quite simple so I strongly agree with your statement that Hez should be guiding us here on what functionality plcolorbar should have. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
