apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [PATCH] Turn apr_table_t into a hash table
Date Sat, 08 Sep 2001 23:54:43 GMT
On Saturday 08 September 2001 15:25, Brian Pane wrote:
> 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.

That would make tables a hash again, which is what I disagree with.  Yes,
creating a new API will require module authors to modify their code to take
advantage of the hash table performance.  But, it keeps the table API refering
to tables, instead of hashes.  This will also require more modifications to
httpd, but in the end, it keeps the code easier to read and understand.

> >  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.

I personally have three modules that use ap_table_elts to iterate through
a table in Apache 1.3.  I can port them to hashes if I have to, but the performance
impact doesn't concern me, because all I want to do with these modules, is
iterate over a small table.

Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message