Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
[...]
> > 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.
>
> As long as it's documented, I think it's perfectly fine. The only
> question I have is this:
>
> What happens if each() doesn't run exhaustively, does that mean that
> $t->get() will continue to give the last value it gave inside the
> each() block and not the first one?
>
> I suppose that's the case, and if so, this should be documented as well.
+1- final patch will be soon forthcoming.
> > Keep in mind this only fixes each(), values() remains
> > fundamentally broken for multivalued keys (the MAGIC_KEYS code in apreq2
> > circumvents this problem, btw).
>
> I'm sure it won't take too long before we will see another patch from
> the productive Joe-machine house :)
:-) Not for this in mp2. Technically the problem lies with
Perl_sv_setsv_flags, which does not copy magic (except for vstrings in
5.8.1+, which explains the current apreq2 code). Once I better
understand the purpose of the (currently undocumented?) mg_copy slot in
struct mgvtbl, I'll see if I can convince p5p to let Perl_sv_setsv_flags
copy magic whenever that slot is occupied.
[...]
> > 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
>
> Shouldn't be the case with the latest Apache::Test, prefork should
> take just a few secs to start. But once we handle that apr-ext/apr one
> source two tests solution, you should be able to do either of the two.
Not using prefork (I haven't abandoned all hope for mp2+worker yet).
>
> >>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.
>
> That's not a redundancy, that's a duplication. If later on you change
> something in one of the tests you need to do it in two places.
Yes, but it's not like the test suite will be silent about it,
so it'd be hard to overlook the problem for very long.
> Instead, it should be one source invoked from both places.
+1.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
