The problem arises because Perl's inheritance is based upon blessed hashes, but Net::FTP uses blessed GLOB's ( courtesy of IO::Socket::INET).

One way around this would be to use an AUTOLOAD sub to extract the Net::FTP glob from your hash and re-dispatch the missing method via that. Something like (untested):

sub AUTOLOAD {
    my $self = shift;
    my $super = $self->{parent};
    ( my $method = $AUTOLOAD ) =~ s[.*::][];
    return $super->$method( @_ );
}
[download]

The problem arises because Perl's inheritance is based upon blessed hashes...

Perl can use all kinds of references as the underlying data structures for objects. You don't have to use hashrefs, it's just that they're the most common, since object data often wants to be stored according to name.

You can see Regexp refs and SCALAR refs being used as objects, in TheDamian's excellent Object Oriented Perl.

So, one way around this is to write a custom ls subroutine in the Custom::FTP module, but this seems to be "wrong" in that it's not inheritance of any kind, rather it's overriding every routine in the Net::FTP module to simply call the parent class's routine..

This isn't necessarily a bad approach, and in fact it's common enough to have a name: MockObject (see that link for references, or try googling "mock object testing").

This sounds like a case for composition and delegation instead of inheritance.

Create a Net::FTP object in your constructor, but don't inherit from Net::FTP. Add an AUTOLOAD that dispatches all appropriate calls to the object. Something like this untested code would work:

sub AUTOLOAD
{
    our $AUTOLOAD;
    my $self        = shift;
    my ($meth_name) = $AUTOLOAD =~ /::(\w+)$/;
    my $method      = $self->{_ftp}->can( $meth_name );
    return $self->{_ftp}->$method( @_ ) if $method;

    # handle error here
}
[download]

Anyway, look in the code for Net::FTP and see how its constructor works, and implement yours the same way.

One of the weaknesses of Perl's OO implementation is that you have to know a class's internal representation in order to inherit from it.

Actually, this is not strictly true. He could use an inside-out-object-like design, and avoid using the object reference to store the data at all. He could initialize the object using the original constructor, and rebless it into his package. Voila, inheritance without knowing about the parent's internal representation. By the way, I am not saying this is the best design in these circumstances, only that it is possible.

package Custom:FTP;
use base qw( Net::FTP );

sub login {
  my $self = shift;
  my @opts = @_;
  if (_not_prod()) {
    $opts[0] = 'testuser';
    $opts[1] = 'testpassword';
  }
  return $self->SUPER::login(@opts);
}
sub _not_prod {
  # check production
}
[download]

We need to modify the *server* it's connecting to as well, which is done in the constructor.
I'd love to externalize the config, that has it's own issues as well (mainly time related)

my $self=Net::FTP->new(@_);
bless $self,shift;
local *r=*$self;
%r=@_;
$r{mystuff}=...;
return$self;
[download]

my $parent=shift;
my $self=do{local *self=*$parent;\%self}
[download]

package My::FTP;
use base 'Net::FTP';

sub new {
# my($class,$host,%args) = @_;
  my $self = Net::FTP::new(@_) or die $@;
  ${*$self}{_custom_data} = 'CUSTOM DATA';
  return $self;
}

sub custom {
  my $self = shift;
  return ${*$self}{_custom_data},"\n";
}

package main;
my $ftp = My::FTP->new(shift);
$ftp->login(shift,shift) or die $ftp->message;
print $ftp->pwd,$/;
print $ftp->custom,$/;
print ref $ftp,$/;

__END__
/
CUSTOM DATA
My::FTP
[download]

try $ftp->{parent}->ls() instead of $ftp->ls()
that should work, right?