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.
there are others of its kind.
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.
there aren't compat finfo tests. it's about the force of reload of Apache::compat in one of the tests.
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.
We need to resolve this for this and other methods which have this problem. It's not so much about the tests but the end users.
[...]
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.
It's a cool idea, but it 1) requires users to change their code, whereas for most case they don't need to with the current Apache::compat 2) it won't work for functions which aren't invoked on $r 3) definititely not a good idea of using compat in CPAN modules because at least of (2).
So if we already require users to change their code, let's just rename the method. How about adding _mp1 postfix for those methods that collide?
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
