Stas Bekman <[EMAIL PROTECTED]> [14-11-2004 17:05]:
Radoslaw Zielinski wrote:
[...]
to support this aliasing feature. Or do you suggest to just alias the namespaces?
Maybe I'm missing something. I was thinking about just aliasing the namespaces.
It's a way more complicated than it seems to be at first sight. Search the dev list's archives for EazyLife to see some of the problems.
Done... OK, so AUTOLOAD is just a can of worms.
But, as the code we're trying to make work already knows which modules does it need to work, we can try a different approach: trap the "use Apache::OldName" calls with a subroutine ref in @INC. Example implementation attached; would this work?
I actually don't really like it, as it's a hack, but... I can't see how this could impact on anything.
Well, let's see what I've missed now ;-)
IMHO, it's a waste of time to try to resolve the namespace issue before the API incompability is resolved (which I doubt is possible or shouldn't be even attempted)
Second, quite a few methods have the same API name, but a totally different functionality. Please see lib/Apache/compat.pm starting from overridable_mp2_api.
I can't see how the two can coexist.
$ cat MP2/Foo.pm package MP2::Foo;
sub sf { print shift() . "::same\n"; }
sub df { print shift() . "::different\n"; }
1;
[...]
...well, maybe in a smarter way. Note, that this allows coexistence of both mp1 and mp2 applications in one interpreter.
The problem is that mp1 and mp2 aren't fully compatible, and there is no way to make them so 100%, mainly. So you have a problem here. You can't run all mp1 and mp2 applications under the same interpreter. Again take a look at lib/Apache/compat.pm %overridable_mp2_api and read:
http://perl.apache.org/docs/2.0/api/Apache/compat.html#Compatibility_Functions_Colliding_with_mod_perl_2_0_API
I've seen it before and still don't see a problem, when we have *different namespaces*. I assume, that the compatibility layer is similar (in effect, not necessarily the implementation) to the attached one.
Can the problem you're seeing be resolved by (I don't know how to do it mod_perl-wide; maybe a per-VirtualHost/Location directive, telling mp2 to return objects blessed into a specific namespace for a given handler?):
package handler_for_mp1_partially_ported_to_mp2; sub handler { my $r = bless shift, 'Apache::RequestRec'; # was Apache2::RequestRec # same thing with $c or whatever ... }
Have you read the URL quoted above? The two APIs behave totally different and it's not possible to figure out at run time, which API generation is desired.
The code you've attached doesn't address that issue and it should be the first issue to tackle. The rest is easier.
I think I've mentioned this already, I'm not disagreeing with you, Radoslaw, that I've wished there was a better way than what we have now. But if you really start implementing your proposal you will see that there are problems in your idea. And some of them might be the showstopper. You are more than welcome to prove me/us wrong with a concrete working code.
Are you saying that this namespace change could -- if implemented -- still get to mp2?
I don't know why nobody else seems to care and joins our conversation, but anything can be changed before 2.0.0 is released, if there is a good reason for it.
-- __________________________________________________________________ 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]
