apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: apr_table_t (was: Re: Release time?)
Date Wed, 19 Sep 2001 19:25:36 GMT
Greg Stein wrote:

>On Wed, Sep 19, 2001 at 11:07:37AM -0700, Brian Pane wrote:
>
>>...
>>If not, I still would like to replace apr_table_elts with a different
>>interface that doesn't make any promises about apr_table_t being
>>an apr_array_header_t.  That will enable us to fix the performance
>>in later releases without breaking people's application code.
>>
>
>First change is to introduce new APIs to do whatever people were referencing
>->nelts or ->elts for. Convert all code to use that, so that the apr_table_t
>structure can be opaque.
>
>Once that is done, then we can change the implementation at will, at any
>time. And the new APIs must exist anyways.
>
>So... I'd suggest working on the APIs first, and getting code to use them.
>*Then* we can look at revamping the table implementation.
>
The original approach that I posted was a traditional iterator object:

  typedef struct apr_table_iter_t apr_table_iter_t;
  apr_table_iter_t * apr_table_iter_make(apr_pool_t *p,
                                         const apr_table_t *t);

  apr_status_t apr_table_iter_next(apr_table_iter_t *iterator,
                                   const char **key,
                                   const char **value);

In my experience, this is an easy change to make, at least in the core
modules (I only had to change half a dozen places in httpd-2.0 to get
it to work.)

Does anybody have thoughts for or against this iterator API?

Thanks,
--Brian



Mime
View raw message