finfo() from Apache::compat collides with the new $r->finfo implementation, the two can't coexist...
this is actually a problem with more than just $r->finfo - in places where the method is redefined and the new one takes different arguments than the old, right?
Different arguments but also the same number of them or none, yes. If the number of arguments is different we can code around it in compat.
actually, finfo might be worse than the others - it returns an object where it used to return _, so we have a whole new class of $finfo->method calls we didn't have before, which will only resolve at runtime. ack.
But the problem with $r->finfo is that it breaks the smoking, whereas others aren't (I think other aren't exercised in both forms)
well, I guess we need to add more compat tests so that finfo won't be so lonely ;)
we could disable the compat finfo tests but keep both implementations until we come up with something better. really, I'm not too worried about the compat tests. we ought to test as much as we can there, of course, but the compat layer has lots of issues now for people who want to use both compat and the new api (as we all know), so I don't see the need to worry too much about tests that illustrate this brokenness.
Solutions?
I have no idea. I'm not inclined to change anything in 2.0 core just because the compat layer has issues - presumably, things are "right" in core (finfo and otherwise).
the easiest fix would be to disable finfo from compat, which I'd be ok with since finfo wasn't really all that popular anyway (unfortunately).
Disabling is imperfect, since the new code is way too different.
imperfect, yes.
May be renaming finfo to finfo_old in compat.pm, so that at least it'll be easier to do the initial transition by just adjusting only one bit and not many. In fact that what I think we should do for all functions in compat.pm that collide. What do you think? May be we should ask the users?
hmm...
what about a new namespace? instead of finfo_old make everyone using compat do this
my $r = Apache::compat($r);
then $r->finfo would be certain to call Apache::compat::finfo. in fact, that approach might help us lots in the long run - CPAN modules could now use Apache::compat (though we still would not endorse it) and not muck around with all the other mp2 namespaces out there. well, maybe it wouldn't help with Apache::Constants and the other non-$r based APIs, but it would be an improvement over how things are currently, at least.
?
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
