httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: naming conventions & data structures (was Re: proposed 2.0 features/layout)
Date Wed, 20 Feb 2002 16:42:25 GMT
Joe Schaefer wrote:
> Stas Bekman <stas@stason.org> writes:
> 
> 
>>>The current header files are inconsistent and have
>>>too much cruft.  Although I prefer using a common
>>>naming convention for both macros and functions within
>>>header files, I could live with adopting a different
>>>scheme for macros.  But the current .h files are not
>>>consistent in this regard, and IMO that needs to change.
>>>
>>
>>+ for common naming convention.
>>
> 
> OK- some clarification on this: macros that have function-call
> semantics (i.e. the args appear only once in the definition)
> should be lower-case;  macros that may not be safe, like say
> 
>   #define apreq_MAX(a,b) ( (a) < (b) ? (b) : (a) )
> 
> MUST have (some) upper-case letters.

why not having all macros UP-cased?

> Another issue I think we should address is what sort of
> data structures we'll use to hold the param's, cookie's,
> and upload's.  In (the still-pending-Jim's release of) 1.0,
> we use apache arrays and tables, and a simple home-grown
> linked list for uploads.
> 
> For 2.0, I'm leaning *against* using ap_hash because it doesn't
> seem to support multivalued keys as well as apache 1.x tables 
> do (tables are implemented as a special kind of apache array;
> the hash-like iterface for an apache table is just a ruse.)
> 
> IOW, if we decide on using a real hash, it probably should be 
> list-valued, and I think that means we'll need to roll-our-own
> version of ap_hash.  IMO it will be simpler to just use a linked 
> list (a'la ap_ring.h) as the underlying structure for everything, 
> and just superimpose a hash-like interface on top of it.
> 
> Thoughts?

If we only could throw a linked list into apr_hash entry, but it works 
only with strings :(

May be we need to raise this issue at apr-dev? I'd prefer to have an
apr-based solution rather than rolling our own. I can see other projects
needing this functionality.

IMO, the fastest (coding wise) solution would be to copy apr_hash and 
let it accept a struct instead of a string as a value. Than we can 
always link from the head struct further to get multi-valued hash.

_____________________________________________________________________
Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
mailto:stas@stason.org  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/


Mime
View raw message