Hi Hez: On 2013-05-12 14:57-0400 Hezekiah M. Carty wrote:
> 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. OK. I will look forward to your further response to what I have said before, and limit what I say here about the C API to just two issues. 1. However you decide to change the C API of pllegend and plcolorbar further after the 5.10.0 release, make sure it is straightforward to propagate it to all our language bindings and as easy as possible to use from those languages. In other words, we don't want to impose some C idea on the other languages if that idea is a bad fit for those languages. Also, I should state I have had some substantial recent experience with pllegend from Python/Numpy, and the current API is actually not that bad to use from that language. >> Andrew said: >> 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. 2. I assume both Andrew and you are referring to my proposal to change the types of const char *labels[] and const char *axis_opts[] in the plcolorbar argument list to const char * const *labels and const char * const *axis_opts What I proposed was to make this change (so that plcolorbar would have the same type for such arguments as pllegend currently does), and use that known pllegend experience for const char * const * arguments to propagate this change through all our C examples which currently use plcolorbar and also propagate the plcolorbar API to the swig-generated bindings and corresponding examples. That does leave the issue of modifying the OCaml bindings for plcolorbar and corresponding examples that use that function consistently with the above change. But that should be entirely straightforward for you since you already know how const char * const * arguments should be handled from your pllegend experience. Hez, should I go ahead with this? I am asking you again because the "If it doesn't break code" qualifier on your above OK is a showstopper since I am virtually positive the above change will break code. That said, the only broken code will be for C and OCaml, and those fixes should be entirely straightforward as I have indicated above. Furthermore that relatively small downside should be more than compensated by the large upside of the proposed update to the plcolorbar API which should make it easier to start propagation of that function to other languages (such as the swig-generated ones mentioned above) following what has already been done for pllegend. 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 __________________________ ------------------------------------------------------------------------------ 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
