Correct way to inherit from 3rd party class

[jonnytheclown]

What is the correct (recommended) way to inherit from an arbitrary
class when I know nothing about its internals (and don't want to know)
but need to hold additional instance variables. The next question is
how should I implement a class that allows other programmers to inherit
from it and hold their own instance variables.

 

[phaylon]

What is the correct (recommended) way

My Answer: Your favorite one.

to inherit from an arbitrary class when I know nothing about its
internals (and don't want to know)

Well, this wipes the private interfaces from the list, so you can only
take use of the public ones. By the way: In Perl it's a package.

but need to hold additional instance variables.

Additional instance-vars for *your* or *that* module? For yours it should
be easy.

The next question is how should I implement a class that allows other
programmers to inherit from it and hold their own instance variables.

In general? With good interface design.

You could tell a bit more of what you're trying to do. For general it
won't be to bad to google for "wrapper pattern".

hth,phay

 

[jonnytheclown]

My Answer: Your favorite one.


Well, this wipes the private interfaces from the list, so you can only
take use of the public ones. By the way: In Perl it's a package.

Programming Perl 3rd Ed. P310. "A class is simply a package". I like
the word 'class', its more OO.

Additional instance-vars for *your* or *that* module? For yours it should
be easy.

Obviously *my*. I no nothing about *that* internally. I don't even
know what the implementation variable is (e.g. hash, array, scalar).
So, how's it easy?

variables.

In general? With good interface design.

You could tell a bit more of what you're trying to do. For general it
won't be to bad to google for "wrapper pattern".

I'm not trying to do anything - yet. It's an academic question.

 

[phaylon]

Please quote only parts you are replying to.

Programming Perl 3rd Ed. P310. "A class is simply a package". I like the
word 'class', its more OO.

As you like, but I prefer 'package', because of the differences.

Obviously *my*. I no nothing about *that* internally. I don't even know
what the implementation variable is (e.g. hash, array, scalar). So, how's
it easy?

You could design a module that acts as wrapper.

I'm not trying to do anything - yet. It's an academic question.

Well the academic answer I think would be: Perl has no *one* way, never.

 

[Sherm Pendley]

What is the correct (recommended) way to inherit from an arbitrary
class when I know nothing about its internals (and don't want to know)
but need to hold additional instance variables. The next question is
how should I implement a class that allows other programmers to inherit
from it and hold their own instance variables.

Have you had a look at "perldoc perlbot"?

sherm--

 

[Anno Siegel]

What is the correct (recommended) way to inherit from an arbitrary
class when I know nothing about its internals (and don't want to know)
but need to hold additional instance variables. The next question is
how should I implement a class that allows other programmers to inherit
from it and hold their own instance variables.

Let me answer the second question first.

The rule is simple: To make a class easy to inherit from, identify
(document) a set of accessors. The set will usually include a creator
method (->new), methods that read or set object variables, plus class
methods to control class variables if such are used. The set should be
kept as small as reasonably possible.

Then write all other methods in terms of these. No exceptions, no cutting
corners.

If a class is written this way, a derived class must define (override)
exactly the accessor methods to guarantee that all methods of the base
class will work with derived objects. It is free to add its own accessors
to additional object (or class-) variables.

To inherit from an arbitrary class that doesn't define such a set of
accessors, you will have to take a look at the implementation to identify
an equivalent set (i.e. a set of methods all others are defined in terms
of). Use that as described above. If you're unlucky, the set will be
large -- it may comprise all methods for an exceptionally badly written
class. In that case, the class can't be usefully inherited from.

Anno

 

[Peter Scott]

To inherit from an arbitrary class that doesn't define such a set of
accessors, you will have to take a look at the implementation to identify
an equivalent set (i.e. a set of methods all others are defined in terms
of). Use that as described above. If you're unlucky, the set will be
large -- it may comprise all methods for an exceptionally badly written
class. In that case, the class can't be usefully inherited from.

You could use delegation on an arbitrary object. Untested:

package SubClass;
use base 'ParentClass';

my %MyAttrib = (foo => 1, bar => 1);

sub new {
my ($class, %arg) = @_;
my $self = bless { }, $class;
$self->{$_} = delete $arg{$_} for grep $MyAttrib{$_} => keys %arg;
$self->{_parent} = $self->SUPER::new(%arg);
return $self;
}

sub AUTOLOAD {
my $self = shift;
(my $attr = our $AUTOLOAD) =~ s/.*://;
return if $attr eq 'DESTROY';
if ($MyAttrib{$attr}) {
$self->{$attr} = shift if @_;
return $self->{$attr};
}
# Might want to use goto & below for traceback
return $self->{_parent}->$attr(@_);
}


In this case, it doesn't matter whether the method that ends up
triggering AUTOLOAD is an accessor or something else. Of course,
you still need to know what all the methods are in the parent
class so you don't accidentally override one you don't want to.