Re: [Libff-devel] Re: libff API

[Rodrigo D. <cu...@uo...>]

Johann Deneux wrote:

> 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=20
>>> they
>>> do, their implementation may be binary-incompatible with C.
>>> These are hypothetical issues, I don't know much about Perl, Python,=20
>>> Ruby
>>> and other languages people like.
>>> Another problem is that every time we touch a structure, every=20
>>> application using libff must be recompiled.
>>> If we hide the structures, recompilation is only necessary when=20
>>> changing
>>> the function prototypes.
>>>
>>   I get your point...how about using both ways?? Having the structs,=20
>> and if the calling language can't handle them directly, it can just=20
>> use the manipulation functions, whereas in C and similars which can=20
>> handle structs, it can be made a lot easier...or perhaps we even=20
>> should make this a C-only version and write wrappers for Perl and=20
>> other languages...I've seen a few libraries which do that...
>>
>
> Ok. But then we have to design our structures very carefully, so that=20
> we hopefully do not need to change them later on.=20

    I was thinking...how much slower is it to use your method?? It=20
wouldn't imply a meaninful delay for a game, would it?? Perhaps we could=20
use that for changing parameters, and make some shortcut functions such=20
as to create an effect, already passing all the parameters in a single=20
function instead of making lots of individual calls...also functions for=20
copying blocks and the like...that should make it just as usable as=20
using structs...

>
>>>>        - Perhaps we should treat compound effects the same way we=20
>>>> treat effects - that would not only make it easier to use, but=20
>>>> would also give us the possibility to build an effect hierarchy...
>>>>        - About effect IDs, how about keeping it in the struct=20
>>>> itself?? That'd make it a bit easier for updating effects...
>>>>
>>>>        Also, about ff_error, I'm in doubt whether we should return=20
>>>> it in all functions, or should return pointers directly(and upon an=20
>>>> error, return NULL)...that would allow for something like this:
>>>>
>>>> eff =3D FF_create_constant(dir, mag, FF_create_envelope(bla bla),=20
>>>> FF_create_trigger(bla bla), FF_create_time(bla bla), flags);
>>>> instead of having to create each of these individually and setting=20
>>>> all their parameters...
>>>>
>>>
>>> Why not. But then we cannot return error codes. The user only knows=20
>>> if it
>>> worked/failed, but has no hint why.
>>>
>>       Can't we use something like errno for the errors?? That's what=20
>> I thought...or even a function FF_get_error...although you may be=20
>> right...
>
>
> We could, but I personnaly dislike this method. In a multithreaded=20
> process, handling errno correctly is not obvious.
> We could use errno if it bought us something, but I just do not see=20
> the advantage of using composition of functions. It only spares the=20
> declaration of a few variables, but the developer may want to keep=20
> track of the parameter blocks ids anyway, which means he will have to=20
> declare variables for those blocks.=20

        I see...ok, so we'll use the original way(returning the error=20
code)...I'll put all this in the header file and send it later tonight...

Rodrigo

--=20
*******************************
* Rodrigo Damazio             *
* *************************** *
* cu...@uo...           *
* rod...@po... *
* ICQ: #3560450               *
* http://www.vros.com/cuddly/ *
* *************************** *
* Engenharia da Computa=E7=E3o    *
* Escola Polit=E9cnica          *
* USP - S=E3o Paulo             *
*******************************