Perl method names are not tied to specific packages

[Rainer Weikusat]

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.

Example
-------------
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();

info($j0);
info($j1);
--------------

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]

[...]

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

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,

http://www.perlmonks.org/?node_id=309952

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:

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

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.