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