[Libff-devel] Re: libff API

[Johann D. <jo...@do...>]

Rodrigo Damazio wrote:

> 
> Johann Deneux wrote:
> 
>> On Sun, 17 Feb 2002, Rodrigo Damazio wrote:
>>
>>> interoperability, why couldn't other languages handle structs??
>>>
>>
>> I don't know if all languages have the notion of structures, and if they
>> do, their implementation may be binary-incompatible with C.
>> These are hypothetical issues, I don't know much about Perl, Python, Ruby
>> and other languages people like.
>> Another problem is that every time we touch a structure, every 
>> application using libff must be recompiled.
>> If we hide the structures, recompilation is only necessary when changing
>> the function prototypes.
>>
>   I get your point...how about using both ways?? Having the structs, and 
> if the calling language can't handle them directly, it can just use the 
> manipulation functions, whereas in C and similars which can handle 
> structs, it can be made a lot easier...or perhaps we even should make 
> this a C-only version and write wrappers for Perl and other 
> languages...I've seen a few libraries which do that...
> 

Ok. But then we have to design our structures very carefully, so that we 
hopefully do not need to change them later on.


>>>        - Perhaps we should treat compound effects the same way we 
>>> treat effects - that would not only make it easier to use, but would 
>>> also give us the possibility to build an effect hierarchy...
>>>        - About effect IDs, how about keeping it in the struct 
>>> itself?? That'd make it a bit easier for updating effects...
>>>
>>>        Also, about ff_error, I'm in doubt whether we should return it 
>>> in all functions, or should return pointers directly(and upon an 
>>> error, return NULL)...that would allow for something like this:
>>>
>>> eff = FF_create_constant(dir, mag, FF_create_envelope(bla bla), 
>>> FF_create_trigger(bla bla), FF_create_time(bla bla), flags);
>>> instead of having to create each of these individually and setting 
>>> all their parameters...
>>>
>>
>> Why not. But then we cannot return error codes. The user only knows if it
>> worked/failed, but has no hint why.
>>
>       Can't we use something like errno for the errors?? That's what I 
> thought...or even a function FF_get_error...although you may be right...

We could, but I personnaly dislike this method. In a multithreaded 
process, handling errno correctly is not obvious.
We could use errno if it bought us something, but I just do not see the 
advantage of using composition of functions. It only spares the 
declaration of a few variables, but the developer may want to keep track 
of the parameter blocks ids anyway, which means he will have to declare 
variables for those blocks.


-- 
Johann Deneux