Ryan Bloom wrote:

>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.
>
To me, a table, even if implemented using apr_hash_t, is different from
an apr_hash_t.  The apr_table_t, as it's been used in the httpd, isn't a
general-purpose set-of-strings.  Rather, it's a set-of-strings-with-special-
support-for-concatenation-and-merging-that-works-well-for-http-headers.
Operations that are essential on tables, like apr_table_merge() and the
corresponding support in apr_table_overlap(), don't make sense for the
general-purpose, type-neutral apr_hash_t.

I'm also opposed to having a declaration like:
   apr_hash_t *headers_in;
   apr_hash_t *headers_out;
in the request_rec.  Architecturally, those objects need to be unordered 
sets with
fast access and the aforementioned merge support.  They don't need to be 
hash tables
specifically.  The implementation could just as well be a balanced tree; 
all the code
in the httpd that uses the httpd shouldn't know or care about how the 
"unordered set"
object is implemented.

--Brian