> >The latter. Having two API's to the same functions should only be done > >as a stop-gap. > > I disagree. It's inevitable to have two APIs, as long as we have two > 'table' types with very different semantics. > > apr_table_t is statically typed (uses char*), and apr_hash_t isn't (uses > void*). > If we did a direct replacement of apr_table_t with apr_hash_t in the httpd, > we'd be sacrificing static type-safety for a lot of code.
So create a simple set of prototypes and macros for a char * version of the hash code, the same way we did for ap_strchr and ap_strchr_c. If you do that, you will be adding probably two or three new functions to APR. > > Also, a LOT of modules using the apr_table_elem macro > >to get the elements from a table. Turning that into an API would break a > >lot of people. > > My patch covers all the changes needed for the core modules. Do you have > any info on the number of 3rd-party modules for 2.0 that use > apr_table_elem? The core is not the only set of modules for Apache. Did you look at mod_perl, php, tomcat? I don't know if any of them use this feature or not, but they aren't a part of the core. Did you look at all of the modules in modules.apache.org, or freshmeat? I know that there aren't many modules for 2.0 today, but at some point, everybody who has a module for 1.3 will want to port it to 2.0. I can currently do that in under one hour for even complex modules. Changing API's like this after we have had 25 releases, makes that harder. Ryan ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
