Perl method names are not tied to specific packages

Discussion in 'Perl Misc' started by Rainer Weikusat, Mar 26, 2013.

  1. That's something which probably also got lost in the noise: A
    subroutine which expects 'an object' (a blessed reference) as argument
    and does nothing with this object except invoking methods on it will
    work with any object whose corresponding class ('package it is blessed
    into _at the moment_') enables access to suitably name subroutines.

    package Named;

    use Scalar::Util qw(blessed);

    sub name
    return blessed($_[0]);

    package Brazilian::Jaguar;

    our @ISA = 'Named';

    sub new
    return bless([], $_[0]);

    sub what
    return 'feline predator';

    package British::Jaguar;

    our @ISA = 'Named';

    sub new
    my $x;
    return bless(\$x, $_[0]);

    sub what
    return 'car';

    package main;

    sub info
    printf("The %s is a %s\n.", $_[0]->name(), $_[0]->what());

    my ($j0, $j1);

    $j0 = Brazilian::Jaguar->new();
    $j1 = British::Jaguar->new();


    Considering that such a subroutine is totally independent of any
    package providing object methods, it should not be tied to one because
    the code could be useful for all kinds of objects. Such a subroutine
    really belongs into a general, non-OO subroutine library.

    NB: The obvious implication is that no 'method' which only expects to
    work with a 'thing' providing access to a certain set of 'named
    properties' actually belongs to the 'the class proper'.
    Rainer Weikusat, Mar 26, 2013
    1. Advertisements

  2. [...]
    Out of curiosity, I did an internet search on 'accessor method' and
    the result was mostly that people think they're supposed to provide
    'public' access the state of an object BUT NOT because this enables
    J. Random Get-shit-done-quickly to - well - get shit done quickly by
    'hijacking' methods of an existing class with the help of supplanting
    the implementation instead of using it as it was supposed to be used
    according to its actual 'public interface'. The 'book' example Ben
    Morrow posted was actually a good example of that: The so-called
    'derived class' can only 'overload' the so-called 'methods' returning
    the price and discount values because the guy who created the
    so-called 'derived class' was familiar with the implementation of the
    so-called 'superclass' to a sufficient degree to know that this change
    wouldn't break anything.

    Also, some of the concerns I voiced about that are by no means things
    "only a totally crazy guy like XXX" could ever come up with: There's
    an article on perl monks about that,

    with the usual string of 'just let me fiddle with it, sweatheart'
    'persuasion replies' attached and a more cogently written
    text, although actually about Java, is available here:

    This also includes some of the things I tried to express but
    more-or-less failed, specifically in the idea that this essentially
    turns an object into a 'C structure with higher overhead' and that
    this is a natural idea for a procedural programmer trying to behave
    'in an object-oriented way' for the sake of outward conformance.
    Rainer Weikusat, Mar 27, 2013
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.