Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Correct way to inherit from 3rd party class

Reply
Thread Tools

Correct way to inherit from 3rd party class

 
 
jonnytheclown
Guest
Posts: n/a
 
      02-21-2005
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.

 
Reply With Quote
 
 
 
 
phaylon
Guest
Posts: n/a
 
      02-21-2005
jonnytheclown wrote:

> 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

--
http://www.dunkelheit.at/

The first rule of project mayhem is: you do not ask questions.
-- Fight Club

 
Reply With Quote
 
 
 
 
jonnytheclown
Guest
Posts: n/a
 
      02-21-2005

phaylon wrote:
> jonnytheclown wrote:
>
> > 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.


Programming Perl 3rd Ed. P310. "A class is simply a package". I like
the word 'class', its more OO.
>
> > but need to hold additional instance variables.

>
> 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?
>
> > 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".
>


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

> hth,phay
>
> --
> http://www.dunkelheit.at/
>
> The first rule of project mayhem is: you do not ask questions.
> -- Fight Club


 
Reply With Quote
 
phaylon
Guest
Posts: n/a
 
      02-21-2005
jonnytheclown wrote:

>> > What is the correct (recommended) way

>>
>> My Answer: Your favorite one.


Please quote only parts you are replying to.

>> 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.


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.

>> 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.


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

--
http://www.dunkelheit.at/
sapere aude.

 
Reply With Quote
 
Sherm Pendley
Guest
Posts: n/a
 
      02-22-2005
jonnytheclown wrote:

> 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--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
 
Reply With Quote
 
Anno Siegel
Guest
Posts: n/a
 
      02-22-2005
jonnytheclown <(E-Mail Removed)> wrote in comp.lang.perl.misc:
> 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
 
Reply With Quote
 
Peter Scott
Guest
Posts: n/a
 
      02-22-2005
In article <cvfcek$r9t$(E-Mail Removed)-Berlin.DE>,
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Anno Siegel) writes:
>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.

--
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Is it correct this way to inherit from a list? Rick Johnson Python 3 03-03-2013 08:40 PM
Re: Is it correct this way to inherit from a list? Ian Kelly Python 0 03-02-2013 05:26 PM
Re: Is it correct this way to inherit from a list? Ian Kelly Python 0 03-02-2013 05:22 PM
Re: Is it correct this way to inherit from a list? Peter Otten Python 0 03-02-2013 05:19 PM
Inherit, hooking into existing 3rd party DLL class Mike ASP .Net 0 04-25-2009 04:58 AM



Advertisments