Sigbjørn Skjæret schrieb am Mit, 04 Okt 2000:
> Just thought I'd say my thoughts on the different parameter setting function
> proposals we've had so far...
>
>
> Individual functions for each parameter:
>
> Pros:
> - None. ;)
:-) compiler provides type check
:-) direct check for valid ranges
:-) small functions everyone can easily understand
:-) avoids huge spaghetti code
> Cons:
> - Litters the API with "thousands" of functions.
is that a cons?
this could be a good point to make the use of this
parameter clear to every user, just write a short
comment for every function
> - If the parameter's type changes, the API has to change.
WOW, IF YOU CHANGE THE MEANING OF A PARAMETER,
THIS WOULD BE A CHANGE IN THE API ALREADY AND
WOULD BREAK BACKWARD COMPATIBILITY !!!
> - If a new parameter is introduced, the API has to change.
but this is backward compatible, so not a problem
>
> Giving a parameter structure:
>
> Pros:
> - Hmmm, none. ;)
>
> Cons:
> - You have to be very careful not to disturb the order of the parameters.
> - You end up with a bunch of duplicates if you have to change parameters.
> - Different compilers can cause different alignments.
:-( would require to recompile every client if you allow him to
access the parameters in your structure
>
> Giving tag-pairs on stack to one function which parses them:
>
> Pros:
> - API never has to change.
>
> Cons:
> - Littering with different tags for each type.
> - It's possible to pass the wrong type.
>
>
> Giving tag-pairs on stack to 3 functions (one for each type):
>
> Pros:
> - API never has to change.
> - One tag for any type.
>
> Cons:
> - It's still possible to pass the wrong type, but it's much clearer since
> the function itself states which to pass.
Ciao Robert
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
