>> - 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 !!!
The 3-function tag-pair API would handle this fluidly, with no problems
what-s
I am planning XML like interface of LAME parameter handling.
I will mail or commit the base code. It will be completely easy and
feature extendable.
---
[EMAIL PROTECTED] // may the source be with you!
>> Both methods (thousands of functions and thousands of tags) are
>> equivalent:
>
> Note:
>
> Both methods (thousands of functions and thousands of tags) are equivalent:
>
> * use one function ( lame_ioctl() ) and thousands of constants
> to tell this function what functionality is actually requested
> * use thousands of functions (lame_x () ) to execute a
>
On Wed, Oct 04, 2000 at 09:42:51PM +0100, Sigbjørn Skjæret wrote:
> 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. ;)
>
> Cons:
> - Litters the API with "thousands"
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
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. ;)
Cons:
- Litters the API with "thousands" of functions.
- If the parameter's type changes, the API has to change.
- If a new
