Re: [MP3 ENCODER] Parameter setting functions...
>> - 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-so-ever... >> - If a new parameter is introduced, the API has to change. > but this is backward compatible, so not a problem Well, you'll prolly bomb out if you try a new function on an old library?! - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Parameter setting functions...
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: >> >> * 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 >> functionality >> >> The difference is that second possiblity is more type safe, and >> the first really looks like you never need to change the API, >> which is only partially true (backward linking is possible, but >> you have still a runtime error, this is often called error >> obscuring). >> >> -- Frank "C programmers hate readable programs" Klemm >> M> I am afraid I actually agree with Frank on this point :-) M> With the tags, you need to add a line in lame.h for each M> variable, as well as 3 lines of code in a big 'switch' M> statement in lame.c -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Parameter setting functions...
> 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 > functionality > > The difference is that second possiblity is more type safe, and the first > really looks like you never need to change the API, which is only partially > true (backward linking is possible, but you have still a runtime error, > this is often called error obscuring). > > -- > Frank "C programmers hate readable programs" Klemm > I am afraid I actually agree with Frank on this point :-) With the tags, you need to add a line in lame.h for each variable, as well as 3 lines of code in a big 'switch' statement in lame.c With functions, you need to add a line in lame.h for each function, as well as 3 lines of code for the function itself in lame.c So they are about the same amount of code, and same amount of stuff in lame.h. But the functions seems a cleaner approach? Anyway, there is a lot more work cleaning up all this ./configure stuff before we can even think about a new API! By the way, if you have not done a 'cvs update' in a while, be sure to do 'cvs update -d' to get all the new subdirectories. (I learned that from the Vorbis mailing list) Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Parameter setting functions...
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" of functions. > - If the parameter's type changes, the API has to change. > This never happens. First you can (mostly) prevent this by avoiding miserliness of bits (Mark! It is easier to pass an boolean through a long double argument than a long double argument through a boolean argument). Secondly I prefer only to add functions. Old functions nevertheless slowly dying if you stop testing them. > - If a new parameter is introduced, the API has to change. > This is a generic property of an API: The API changes if the API changes. You can't avoid this by reducing the API entry point to one function (otherwise the Linux API has been not changed from Linux 0.01, it is still the sys_call() function, which is an intreq 0x80). Don't mix the two items "number of API entry points" and "complexity of an API". Math libs don't become easier by: math_call ( MATH_SIN_TYPE , MATH_ONE_ARGUMENT, MATH_DOUBLE_ARGUMENT, (double)0.707 ); math_call ( MATH_SQRT_TYPE, MATH_ONE_ARGUMENT, MATH_DOUBLE_ARGUMENT, (double)1.732 ); math_call ( MATH_POWER_TYPE, MATH_TWO_ARGUMENTS, MATH_DOUBLE_ARGUMENT, (double)2.616, (double)1.616 ); Real programmers also merging all other functions (lame_ioctl, math_call, sys_call, X11_ioctl, ...) and use only one function doing all things: void do_stuff ( int do_, ... /* stuff */ ); Then you don't need a linker and can do linking by a hex editor ;-) Also possible are: DoIt (); PerformDataFunction (); HandleStuff (); do_args_method (); snafucate (); do_args_method ( LIB_SELECT_LAME | LIB_LAME_SETUP_FUNC | LIB_LAME_SETUP_SFREQ | LIB_SET_DBL_TYPE, (double)44100 ); do_args_method ( LIB_SELECT_POSIX | LIB_POSIX_IO_FUNC | LIB_POSIX_IO_WRITE | (LIB_SET_INT_TYPE<<10) | (LIB_SET_VOIDPTR_TYPE<<5) | (LIB_SET_SIZET_TYPE<<0), (int)fd, (void*) buff, (size_t) length ); do_args_method ( LIB_SELECT_CLIB | LIB_CLIB_BASE_FUNC | LIB_CLIB_BASE_EXIT | LIB_SET_INT_TYPE, (int)0 ); > 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. - you can't add a translation layer between API and lib. > 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): > Why 3 functions? You only need an int ;-) > 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. > Giving tag-pairs on stack to one function which parses them: const char* lame_ioctl ( enum TagItem, const char* TagValue ); returns NULL or the actually set parameter. 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 functionality The difference is that second possiblity is more type safe, and the first really looks like you never need to change the API, which is only partially true (backward linking is possible, but you have still a runtime error, this is often called error obscuring). -- Frank "C programmers hate readable programs" Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Parameter setting functions...
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/ )
