Correct way to inherit from 3rd party class

Discussion in 'Perl Misc' started by jonnytheclown, Feb 21, 2005.

  1. 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.
     
    jonnytheclown, Feb 21, 2005
    #1
    1. Advertising

  2. jonnytheclown

    phaylon Guest

    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
     
    phaylon, Feb 21, 2005
    #2
    1. Advertising

  3. 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
     
    jonnytheclown, Feb 21, 2005
    #3
  4. jonnytheclown

    phaylon Guest

    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.
     
    phaylon, Feb 21, 2005
    #4
  5. 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
     
    Sherm Pendley, Feb 22, 2005
    #5
  6. jonnytheclown

    Anno Siegel Guest

    jonnytheclown <> 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
     
    Anno Siegel, Feb 22, 2005
    #6
  7. jonnytheclown

    Peter Scott Guest

    In article <cvfcek$r9t$-Berlin.DE>,
    -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/
     
    Peter Scott, Feb 22, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike
    Replies:
    0
    Views:
    403
  2. Peter Otten
    Replies:
    0
    Views:
    150
    Peter Otten
    Mar 2, 2013
  3. Ian Kelly
    Replies:
    0
    Views:
    123
    Ian Kelly
    Mar 2, 2013
  4. Ian Kelly
    Replies:
    0
    Views:
    120
    Ian Kelly
    Mar 2, 2013
  5. Rick Johnson
    Replies:
    3
    Views:
    120
    Jason Swails
    Mar 3, 2013
Loading...

Share This Page