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 08:43:09 GMT
Geoffrey Young wrote:
> Stas Bekman wrote:
>>Geoff, any chance we can get this one resolved? As we may make a new
>>release soonish, we can't have this collision in Apache::compat and
>>APR::Finfo get out from the dev release.
> I really don't know the answer to this.  the new finfo API is a proper
> interface, and I don't see removing it just to appease the compat layer,
> especially since it's just exposing a problem that many compat methods have.

I've never suggested that. I'm just pushing to get the conflict resolved 
before we release a new version.

>>>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.
> actually, I meant Apache::compat->new($r) but you get the idea :)
>>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
> 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 would
> assume we can do the same for $r->server, $r->parsed_uri, etc. which leaves
> only stuff like Apache->server_root_relative.  we can probably come up with
> 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).

>>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?
> I don't think that's a good idea at all - you might as well not have a
> compat layer at all then.
> in the short term, though, I'd be in favor of removing
> Apache::compat::finfo() if the smoke failures are bothersome - finfo() just
> isn't all that popular (unfortunately).

The smoke is only showing that users may have the same issues in their code, 
besides not letting to smoke real problems out.

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.

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

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

View raw message