perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2] finfo collisions with Apache::compat
Date Wed, 10 Dec 2003 19:13:11 GMT
Geoffrey Young wrote:
>>>I still think this is a solution worthy of investigation.  I just
>>>don't care
>>>about 1) and I think we might be able to work around 2) somewhat - I've
>>>created subclasses that return my own objects for $r->connection, so I
>>>assume we can do the same for $r->server, $r->parsed_uri, etc. which
>>>only stuff like Apache->server_root_relative.  we can probably come up
>>>something clever there too :)
>>This still requires heavy modifications in the user code. If they do so,
>>they should just move to the new API. The idea behind is to
>>have to run the code unmodified (so neither my renaming idea fits in).
> hmm.  I don't see "heavy modification."  what I'm suggesting is that
> Apache::compat be a subclass of Apache.  thus, like any true subclass,
> everything remains the same for the user save the constructor.
> the modification would now be two lines
> use Apache::compat;
> my $r = Apache::compat->new($r);
> rather than just
> use Apacahe::compat;
> I don't see heavy modification here at all for anything that comes from $r,
> $c, or $s.  where it gets tricky are the class methods like
> server_root_relative(), and yes, those would be problematic for this approach.
> and, of course, it's lots of work for us to rewrite it all, too :)  and I
> really don't have much of an interest in the compat layer anyway, so I'm not
> all that motivated to work on it.

Yes, it's too much work and it won't work for non-methods.

>>The smoke is only showing that users may have the same issues in their
>>code, besides not letting to smoke real problems out.
> in the case of compat there definitely will be conflicts whether it shows up
> in smoke or not.  that's been well established, right?  this is why I don't
> think that smoke is that big a deal with compat - we know the issues are
> there, so fixing finfo specifically is just a short-term solution.  what
> really needs to happen is that we need to fix the compat layer so that it
> won't cause the problem for users.  that, or just live with smoke driving
> known issues to the surface.

I guess you don't realize what the problem is with smoke. These known issues 
prevent from running smoke to discover unknown ones. It's only finfo that gets 
on the way.

>>If there is no co-existence solution it needs to be removed. But not
>>having a compat layer at all is not a good solution. I suggest to move
>>all those colliding methods to a different package and let people use it
>>on their own risk. Or an alternative approach is to keep Apache::compat
>>but have an import method which will enable the colliding functions on
>>demand. So if you'd want finfo, you'd say:
>>use Apache::compat qw(Apache::RequestRec::finfo);
>>and it'll build this compat method. There will be a big warnings
>>suggesting possible collisions with the 2.0 API.
>>At the same time the harmless compat API will work as before.
> yeah, I think we had discussed that too, and it seems like a decent approach.

OK, let's do it then.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message