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.
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 http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
