apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apr/tables apr_tables.c
Date Sun, 21 Jan 2001 00:03:05 GMT

> > Another feature that remains useful, is to be able to iterate over the
> > array, and know that you are getting data out in the same order that it
> > was originally added.  That feature does not exist with hash tables.
> 
> Tables' API/semantics don't provide for that. Tables were intended to be a
> hash, but the implementation never got there.

Sure they do.  Take a look at apr_table_add, that just adds another
element at the end of the table, and then I can call apr_table_do, and
iterate over them, or I can get the elements directly and iterate over
them.

> Regardless: nobody uses binary tables, and I don't know that anybody
> plans to anywhere in the code. Hash tables are a much better than
> binary tables. Tables (normal or binary) are linear-time for lookup,
> even though they export a key-based style like a hash table.
> Why do we need binary tables?

Nobody uses them because they were just added at the beginning of 2.0, and
nobody has gone through the code yet to see where they are useful.  I seem
to recall that people were talking about making the request_rec->notes
table a binary table so that binary data could be passed between
modules.  Beyond that I would need to actually investigate the code a bit
more.

As far as why do we need them, with the hash implementation, why do we
need text tables anymore?  They are the same basic thing, and the hash
implementation can provide for both text and binary data, so couldn't
everything be implemented as a hash table?

Regardless, since people in the group have wanted binary tables for over
two years, it would have been very nice if this had been discussed before
they were simply removed.  I would go search the archives for all the
times Lars and Dirk mentioned needing binary tables, and where they wanted
them, but searching our archives isn't easy right now, and I am in the
middle of other work.  I'll try to find it later tonight.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message