Hi, I reenter the discussion that I proposed some days ago
Andrew Ross ha scritto:
> On Sat, Aug 08, 2009 at 01:14:53PM +0200, Werner Smekal wrote:
>> Hi Arjen,
>>
>>>> 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.
>> Yes, enumeration of #define macros would be much better and faster.
>> Comparing strings is surely not the best.
>>>> 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.
>>>>
>>> I agree that a void * argument would be very bad for most languages,
>>> if not all, and it leaves the interpretation of the value up to the
>>> programmer. What about filling a structure instead?
>> Or even better an union. It's always problematic how such things
>> should be solved, but I even have another idea. Why not get ALL
>> information in one struct. e.g.
>>
>> plgetattr( struct plAttributes* att);
>>
>> struct plAttributes {
>> int width;
>> int frontcolor;
>> int backcolor;
>> ......
>> }
>>
>> You will not use such functions in critical situations anyway (or?),
>> so speed is not a problem and you could get all attributes at once. On
>> the other side, maybe difficult to port to other functions, but
>> something like structs or tables all languages have, or?
>
> The big downside of this is that every time you add a new function
> you have to change the structure which is formally an API change (as
> opposed to just an API addition).
>
> Not all languages have structures. For example in f77 you end up resorting
> to common blocks or other such ills.
I agree that mapping C structs to other languages is not portable, even
simple f90 derived types are not easily mappable to a C structure, so it
would nullify the advantage of the approach.
>
> I would suggest something like
>
> plgvarf(int varid, PLFLT * val)
>
> where varid is the #defined id of the variable to get. You could make enums
> of these in languages which support them. val is the returned value. Almost
> all of the get functions will return a PLFLT. For those where a int or
> string is returned we could have
>
> plgvari(int varid, int * val)
> plgvarc(int varid, char ** val)
>
> This maintains all typechecking on the returned value and avoid void *. It
> will
> also be easily ported to all other languages.
>
> Where this more messy than the current approach is where you want to get a
> set of returned values (e.g. plgvpw returned viewport limits - 4 numbers).
> I don't know if there is a good generic solution to this.
This looks really reasonable; for returning a set of values, there could
be an additional size parameter, either in the same functions or in a
"vectorized" set of corresponding functions, that limits the size of the
array to get/set, e.g.
plgvariv(int varid, int * val, size_t n)
plgvarcv(int varid, char ** val, size_t n)
(I suppose you meant that the char version would allocate the space, in
this case it would allocate an array of pointers); in f90, this approach
could reduce to a single interface plgvar(varid, val) to all the
subroutines that handle the different types, array or not, maybe some
work should be done for handling the char case, I can contribute for
this if needed.
best regards, Davide
--
============================= Davide Cesari ============================
Servizio IdroMeteorologico ARPA Emilia Romagna
Area Modellistica Numerica e Radarmeteorologia
Phone/Fax: +39 051525926/+39 0516497501
E-mail: dces...@arpa.emr.it
Home page: http://www.webalice.it/o.drofa/davide/
Address: ARPA-SIM, Viale Silvani 6, 40122 Bologna, Italy
========================================================================
------------------------------------------------------------------------------
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
