Doug MacEachern wrote:
> On Fri, 28 Sep 2001, Stas Bekman wrote:
>
>
>>patch:
>>- this patch implements PerlSetVar and PerlAddVar
>>
>>changes:
>>- the first patch was broken, you cannot use apr_table_overlap for merging
>>SetVar tables(in merge_table_overlap_item) , because we want to overlap
>>only the values for the keys which arenot in the current dir_config table.
>>So I had to do it manually. Do you think we should submit a patch for
>>apr_table_overlap, to have a third flag that does what we want?
>>
>
> sure. but, in 1.x we just use overlay_tables, why do we need to change?
> will the change break anything expecting 1.x behavior? can you give an
> example of whats going on here? (i'm not really familar with what to
> expect here)
If I understand how merge works here is the situation, imagine imaginary
Set command that does set into some table, and there is some subsection,
so we will have the dir merge happening.
<Section Foo>
Set A 1
Set B zzz
<SubSection Bar>
Set A 2
Add A 3
</SubSection>
</Section>
Now before the table is enquired from the *subsection*, the dir_merge
happens, you have a few ways to merge the Sets, so if you dump the table
as it's seen via dir_config the results could be:
a) A 1 2 3
B zzz
b) A 3 2 1 (or even 2 1 3)
B zzz
c) A 2 3
B zzz
I've implemented c) as it seems the most logical to me. Why? If you
*Set* some key/val in a subsection, you don't expect to inherit some
values for the same key from the parent section/dir. You do *Set*.
So my "algorithm" is simple, if the key is set in the dir, I ignore the
values for the same key in the parent dir (I don't merge them). Now if
the key is not set in subsection, I do want to inherit the key/val from
the parent.
Am I wrong here?
I didn't look at table_overlay in 1.x, may be they have changed it in
apr_, but do you agree that simply slurping two tables together is not good?
I think apr_table needs a third constant for apr_table_overlap, since
that's where it belongs, IMHO.
>>- now the test in the next patch (of dir_config) is done properly and
>>tests the failure I didn't notice in the previous patch.
>>
>
>>+ modperl_config_dir_t *dcfg = (modperl_config_dir_t *)dummy;
>>
>
> as mentioned before, you need to cvs up, dummy has been renamed mconfig.
yes, yes, yes, I'm doing that right now :) next time will make sure to
diff after a fresh 'cvs up'.
>>+/* take the 'base' values, and override with 'add' values if any */
>>+#define merge_table_overlap_item(item) \
>>
> this should be a MP_INLINE-d function.
ok, so what's the rule of thumb of when some code should be a macro and
when a function and when an MP_INLINEd function?
From what I remember from C++ (or was it C?), you use inline when some
code is really short, and used only a few times so you won't end up
duplicating the same machine code a few times.
Thanks!
_____________________________________________________________________
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]
