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 14:02:56 GMT

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

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.

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

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


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

View raw message