On Sat, Jan 20, 2001 at 04:03:05PM -0800, [EMAIL PROTECTED] wrote: >... > 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.
The implementation allows for it, sure. But the table was intended to be a hash. And hash table semantics don't provide for ordering. > > 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. They were added prior to hash tables. I bet those "useful" spots would be more useful as a hash table :-) I see no conceivable need for the binary table, so there is no need to multiple-path our code with text and binary tables and hashes. Drop the bloat, drop the maintenance, etc. >... > 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? Absolutely. I would toss the text tables, too... if I could :-) But that data type is just too ingrained and widespread. Nobody was touching binary tables, so it is easy to toss them and refer users to hash tables instead. > Regardless, since people in the group have wanted binary tables for over > two years, Their needs are met by the new hash table that Tony did. Cheers, -g -- Greg Stein, http://www.lyra.org/
