On Wed, Aug 5, 2009 at 4:22 PM, Hazen Babcock<hbabc...@mac.com> wrote: > Davide Cesari wrote: >>> I'm inclined to add at least a function to get the current pen width and >>> the current plcol0 index. >>> >>> Any objections to this expansion of the API? Any objections to adding >>> getters in the future for all other PLplot setters? How about the >>> save/unsave feature as suggested by Steve? >>> >>> The schedule would probably be to add the pen width and plcol0 functions >>> before the next release and then add the rest after the 5.10 release. >>> >>> -Hazen >> >> >> Just a comment on these getter/setter functions: since, as far as I >> understand, the biggest obstacle to plplot development is the >> propagation of new function to all language bindings, wouldn't it be >> wiser to make a progressive switch to a more "encapsulated" API style, >> like providing a single getter and setter set of functions with a char >> argument specifying what to get or set, and the value (or pointer to >> array of values) to set or pointer to value(s) to be get, one per >> supported type? This would allow to add new settable parameters without >> API change and for languages supporting function overloading or dynamic >> typing (I can think of f90, C++, python), this would probably reduce to >> just a single getter and a single setter function. >> >> I mean something like this, at your choice: >> PLINT fontpar[3]; >> PLINT fontfamily, fontstyle, fontweight; >> /* either: */ >> plgetint("font", fontpar); >> /* or */ >> plgetint("font_family", &fontfamily); >> plgetint("font_style", &fontstyle); >> plgetint("font_weight", &fontweight); >> >> The current get/set could be left as legacy functions in order not to >> break the existing applications. > > I like this idea/approach. Is there a reason not to reduce it even further? > > plget(const char *, void *) > plset(const char *, void *) > > It seems that either way the user would have to call the function as > intended to avoid memory corruption. > > Any objections to my implementing this & attempting to make it fairly > comprehensively cover most of what can gotten and set in PLplot core? > Likely the bulk of the work would be done post 5.10.
While I like the API simplification this could provide, I have two primary concerns: First, could the first argument - the field to get/set - be an enumerated type of some sort? This should help catch typos at compile time rather than run time. (PL_LINE_WIDTH rather than "line width"). Additional fields would then require adding elements to the enumeration which, as I understand, should not break existing code. Second, the void* approach may not translate well to other languages. I'm not sure if there is a way to do this in C that would translate well to the other PLplot-supported languages though. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel