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 compat.pm 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 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]
