apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: [PATCH] Turn apr_table_t into a hash table
Date Sat, 08 Sep 2001 22:25:29 GMT
Ryan Bloom wrote:

>>>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.\
>
Yes, macro wrappers would work.  But if we use that approach, it would
be advantageous to use macro names like "apr_table_get" so that all
the existing httpd code and 3rd party modules can be used without 
modification.
This would be functionally equivalent to the "implement apr_table_t using
apr_hash_t" approach that I prefer.

>>> 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?
>
mod_perl and Tomcat (mod_jk) don't use apr_table_elts.  PHP contains two 
calls to it.

>  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.
>
Based on how infrequently apr_table_elts is used in the core and in PHP and
mod_perl, and how small the code change required to use the iterator API is,
I'd be extremely surprised if the removal of apr_table_elts substantially
impaired one's ability to port a module from 1.3 to 2.0 in under an hour.

--Brian



Mime
View raw message