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.
> 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.
> ---------
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
