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
