Doug MacEachern wrote:
> On Fri, 21 Sep 2001, Stas Bekman wrote:
>
>
>>If I implement the storage as an apr_hash_t, the look up is much faster
>>and simpler (that's what we want, since we mostly do lookups at the run
>>time). But how do I maintain a list? Luckily apr_hash_t want a void type
>>for the value so I can pass it a list.
>>
>
> you could do:
> typedef struct {
> int num;
> union {
> const char *val;
> apr_array_header_t *values;
> } val;
> } modperl_var_t;
>
> if (num > 1) use the values, else use the val. but that'll get messy.
> might be better off to always use an apr_array_header_t for the values.
>
>
>>Alternatively we could always use a hash of lists and always add values
>>to the lists. Less logic, more space, slower on average (assuming that
>>it's rare that we have a more than one value for one key).
>>
>
> shouldn't be too much slower. extra space should on be on the order of 20
> bytes, not too bad.
sounds good, but as you say below there is a lot of code to write to
support this.
>>It'll be very nice if APR::Table could handle this automagically. Or
>>should we have a new apr class to handle hashes of lists?
>>
>
> APR::Table is an apr_table_t, not an apr_hash_t.
> if Perl{Set,Add}Var is moved to an apr_hash_t, it will need its own api.
> i don't know if its even worth implementing Perl{Set,Add}Var as
> apr_hash_t, the table per-dir is never more than a few entries.
So on fetch
@values = $r->dir_config('key');
it's ok to iterate through the whole apr_table_t to make sure that all keys
are fetched. I'm not sure how the tied interface APR::Table->FETCH accomodates
this? I should look at the recent patches.
So basically what you say is that using apr_table_t should be fine for the needs
of Perl{Add|Set}Var, right?
>>---------
>>
>>now the second part: dir_config
>>
>>is that correct?
>>
>>@values = $r->dir_config('key');
>>@values = $r->dir_config->{key};
>>
>
> right.
>
>
>>%hash = $r->dir_config; # Hash of lists!
>>
>
> the 1.x api returns a $table object, 2.0 should do the same.
> which is also what you second example does:
> @values = $r->dir_config ->{key};
> ^^^^^^^^^^^^^^
> there's no way to treat that different from $r->dir_config; without
> examining the op tree, which i don't think we want to do.
that was my mistake, I meant:
$obj = $r->dir_config;
Thanks, Doug!
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
