perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: [mp2] finfo collisions with Apache::compat
Date Wed, 10 Dec 2003 04:13:09 GMT

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.

>> 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 :)

> 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).


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

View raw message