Re^3: GLOB reference problem

When you want to extend an existing class, you have two options: inheritance and aggregation. If you go the inheritance route your new method would look something like this:

use base qw(Net::FTP);   #5.8

#or for 5.10 and up
#use parent qw(Net::FTP);

sub new {
  my ($pkg, $server, $user, $timeout, @args) = @_;

  # some special class specific stuff

  # ... is params for super class structure
  my $self = $pkg->SUPER::new(...); 
  $self->server($server);
  $self->user($user);
  $self->timeout($timeout);
  $self->initialize();

  # some special class specific stuff

  # if SUPER::new is well behaved, $self will be a member
  # of the $pkg class even though it was built by the
  # the super class.
  return $self;
}
[download]

If you go the aggregation route you might do something like this:

sub new {
   my ($pkg, $server, $user, $timeout, @args) = @_;

  # some special class specific stuff

  # ... is params for super class structure
  my $ftp = Net::FTP->new(...);
  $ftp->server($server);
  $ftp->user($user);
  $ftp->timeout($timeout);
  $ftp->initialize();

  my $self = { ftpHandle => $ftp };
  return bless($self, $pkg);
}
[download]

If you want your own class to be implemented using a hash, you would go with the aggregation approach since Net::FTP doesn't return a hash. If you want to return the same kind of implementation as Net::FTP, then you would follow the inheritance pattern. You might find the sections on inheritance and aggregation in perltoot worth a read.

Best, beth

Comment on Re^3: GLOB reference problem Select or Download Code

Replies are listed 'Best First'.
Re^4: GLOB reference problem by jerryhone (Sexton) on Oct 05, 2009 at 11:12 UTC
Thanks Beth. Unfortunately I need to completely avoid Net::Ftp. I don't want to extend that class - I need to create my own standalone class with the same interface. Jerry	[reply]
Re^5: GLOB reference problem by almut (Canon) on Oct 05, 2009 at 12:30 UTC
Net::FTP's constructor calls IO::Socket::INET, which calls IO::Socket, which in turn calls IO::Handle. And IO::Handle uses `gensym` to create the glob. In other words, if you wanted to fake a (totally functionless!) object of same type, you could try: `#!/usr/bin/perl my $ftp = Net::FTP::Faked->new(); print "$ftp\n"; # Net::FTP=GLOB(0x63c430) package Net::FTP::Faked; use Symbol; sub new { my $ftp = gensym; bless $ftp, "Net::FTP"; }` [download]	[reply] [d/l] [select]
Re^5: GLOB reference problem by ELISHEVA (Prior) on Oct 05, 2009 at 11:59 UTC
Update: I missed the part about this being a dummy class. You want to emulate the interface of Net::FTP but you can't use Net::FTP?! It is part of the core - you don't even need to use CPAN. Unless this is a school project or an educational exercie, this seems like a lot of reinventing the wheel. If you really, really have a good reason, then you might try studying the source code to get a better idea of how it is done. All of the source code is available via CPAN. Quite honestly, if this is not a learning project and you need help figuring out how to do this, you are likely in way over your head with the project. If it is a learning project, it is very important that you define your scope and use cases very carefully before you begin, otherwise you will never reach the end. When you study that module you will quickly see that there is a lot of complex code supporting that module. Code and documentation for that module alone is about 1800 lines. If your "can't use" rule extends further to its prerequesites (e.g. IO::Socket) the number of lines jumps up dramatically. Even a guru programmer isn't going to write and thouroughly test that in less than a week. Assuming 1000 of that is lines of code, COCOMO 81 would put the time estimate at 3 months full time work! (that's for a single person of average skill). Best, beth	[reply]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks