apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: apr_table_t (was: Re: Release time?)
Date Wed, 19 Sep 2001 21:33:22 GMT
On Wednesday 19 September 2001 02:28 pm, Justin Erenkrantz wrote:
> On Wed, Sep 19, 2001 at 12:25:36PM -0700, Brian Pane wrote:
> > 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?
>
> +1.  Accessing the structures directly goes against our philosophy.

Which philosophy would that be?

Tables have worked this way for a very long time.  Take a look at the docs
in apr_table.h:

    /* This has to be first to promote backwards compatibility with
     * older modules which cast a apr_table_t * to an apr_array_header_t *...
     * they should use the table_elts() function for most of the
     * cases they do this for.
     */
    /** The underlying array for the table */
    apr_array_header_t a;

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

Mime
View raw message