Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
> > Thanks in advance for looking this over- I'll be happy to
> > explain it in more detail if anyone is interested.
>
> I think it'd be beneficial to document the logic in the code that
> implements it.
>
> And also update the APR::Table manpage :)
Gladly, assuming the new FETCH (eg. scalar get()) behavior
is desirable: eg within an each() iteration, scalar
$t->get("foo") will pick the _current_ "foo" value, not
necessarily the first "foo". The old behavior (
$t->get("foo") fetches the first value ) still applies
everywhere else.
Keep in mind this only fixes each(), values() remains
fundamentally broken for multivalued keys (the MAGIC_KEYS
code in apreq2 circumvents this problem, btw).
[...]
> But if you don't mind leave that test alone and instead extend
> t/response/TestAPR/table.pm, since that's where it all tested.
True, but it's MUCH quicker to run the standalone apr-ext tests
while developing: eg.
% t/TEST -no-httpd apr-ext # avoids ~30sec httpd startup delay
> As mentioned before, I'd love to see apr-ext/ and non-apr-ext somehow
> re-using the same tests, instead of duplicating and spreading them all
> over, making it hard to maintain.
>
> If it's too much of a bother, I can do that move.
Why not just copy them there instead of moving them?
I don't see the harm in having some redundancy in the
test suite.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
