Apache::compat provides mod_perl 1.0 backward compatibility implementation. And everything works just fine as long as the API has a different name. However there is a problem if a certain method has the same name but a totally different functionality. Here is an example:
As explained here: http://perl.apache.org/docs/2.0/user/porting/compat.html#C__connection_E_gt_remote_addr_
in mod_perl 1.0 you'd say:
use Socket 'sockaddr_in'; my ($port, $ip) = sockaddr_in($r->connection->remote_addr);
i.e. $r->connection->remote_addr was returned a packed socket information.
However in mod_perl 2.0 lingo (read: Apache 2.0 lingo), $r->connection->remote_addr returns an APR::SockAddr object (read: an opaque object, to which you need to use methods to access its values). So to accomplish the above you need to do:
require APR::SockAddr;
my $sock_addr = $c->remote_addr;
my ($port, $ip) = ($sock_addr->port_get, $sock_addr->ip_get);
this is a 1:1 mapping to the Apache 2.0 C API.
So if we provide a back-compat implementation in Apache::compat and it gets loaded the real 2.0 API can no longer be used.
What I suggested is that we need some sort of scoped pragmata, so we can say:
{
use mod_perl::compat;
my ($port, $ip) = sockaddr_in($r->connection->remote_addr);
}
my $sock_addr = $c->remote_addr;
my ($port, $ip) = ($sock_addr->port_get, $sock_addr->ip_get);so I can use both APIs and enable the back-compatibility functionality only in the needed scope. Of course this doesn't make the porting as simple as enabling Apache::compat, but it solves the API breaking problem. If it was only possible to make the scoping work.
__________________________________________________________________ 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
