>> 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 compat.pm 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. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
