(It wouldn't surprise me if this middle-man-skipping business is one of those things about Perl's take on OOP that make OO purists run for the hills, and maybe it is a result of those concerns that super.super.hello() makes Java have a cow. Dunno.)

Kinda :-)

It's not that you can do this in Perl (you can also do it in many other OO languages) but the fact that you want to do this is a sign that there is something seriously odd with the class hierarchy.

If a subclass isn't sharing behaviour with a superclass it's probably not an isa relationship - so inheritance is probably not what you want.

Seconded.

There's also another very important rule that I got from "Smalltalk Best Practice Patterns" (by Kent Beck) (I believe), which should be required reading for anyone doing serious OO. Yeah, it's all about Smalltalk, but most of the rules apply to any late-binding OO language like Perl.

The rule is that superclass calls should be made only to the same-named method. In other words, if you're in foo, you should never be calling SUPER::bar. This is the sign of a misunderstanding about SUPER and about objects in general. The point of SUPER is to extend a parent class behavior, not mix it up.

Wanting to "call the code two levels up" or "call a method other than your own name" are both signs of muddled thinking or an extremely bad class design.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Thanks for the ref to the Beck book.

Yeah, it's all about Smalltalk, but most of the rules apply to any late-binding OO language like Perl.

Could you or some other knowledgeable monk clue me in about this business of "late-binding"? I googled the definition, but I'm having a much harder time finding some bird's-eye picture of the fundamental qualitative differences between OO languages that are late-binding and those that aren't. I vaguely gather that early-binding may be tied to strong typing, but this is just a guess.

Wanting to "call the code two levels up" or "call a method other than your own name" are both signs of muddled thinking or an extremely bad class design.

Yes, agreed, and I don't recall ever needing to do this in classes I have coded, but unfortunately one often has to work with class hierarchies designed by others. In fact, what motivated this meditation was a practical problem posted in SoPW; one simple solution to that problem amounted to "skipping the middle man".

Without knowing much of the OO theory behind it, I've figured that the ability to "skip the middleman" is, like the goto LABEL facility, something to use sparingly, but nice to have available for the once in a blue moon when you really need it (otherwise Perl would have simply disallowed it). But in light of your and adrianh's comments, I regret having made the whole maneuver sound as innocuous as I did.

the lowliest monk

There's also another very important rule that I got from "Smalltalk Best Practice Patterns" (by Kent Beck) (I believe), which should be required reading for anyone doing serious OO.

Totally agree. One of my favourite books.

(and everybody should have to learn Smalltalk once in their life anyway :-)

It looks like your problem is that your inheritance is broken. In your example, Dad inherits from Grandpa, but then decides to replace hello() without calling the hello() in Grandpa. That's not a good thing necessarily. You may not see it in this very simple example, for for more complex real world things, Grandpa may need to run its hello() to do things to make everything else keep working. The sub-classes don't usually know about those things, and they shouldn't.

After that, you create a Me class that inherits from Dad. When it calls hello(), it gets the one from Dad. That's the way it should be because you said Me inherits from Dad. You shouldn't get to peek inside the @ISA for Dad to skip a level to call Grandpa::hello(). The @ISA may change, and if it does, you're hanged yourself.

Perl offers "no help in hard-coding method names" because you shouldn't be doing that. If you want to use inheritance, you should be inheriting the behaviour of the superclass. If you don't want that behaviour, why are you inheriting it instead of overriding it?

You may think you want this in certain situations, but eventually you'll get burned. When you don't let the entire chain do what they want to do, something is going to get out of sync because code doesn't run when it should. That's a terrible thing to have to track down.

Furthermore, if you're using SUPER:: outside of the internals of a class, you're probably not doing the right thing. A good design hides all that stuff at the user level.

Agreed. (Please see my reply to merlyn.)

But now, given such strong opinions against doing something like $me->Grandpa::hello() I am dumbfounded by the fact that Perl supports it. Why does it??? Was this just a bad idea that somehow got through in the design of Perl?

the lowliest monk

It's useful when you have multiple-inheritance, to say which of your parent classes to start searching.

It's also useful when SUPER:: would be wrong... like a flyweight class.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Given such strong opinions on multiple inheritance or data hiding or a myriad of other items that perl doesn't follow ... well, I think that tells you why. Because perl isn't dogmatic about anything.

If you really want to do it, you can. Which is way better than certain other languages who think they know better than the programmer.

I think that:

$me->Grandpa::hello()
[download]

is the same as:

Grandpa::hello($me);
[download]

which isn't OO. You can test it like so:

use strict;
package other;

sub hello { print "otherwise @{[ref shift]}\n"; }

package Grandpa;
sub hello {
  my $class = ref $_[0] || $_[0];
  print "How do you do, from $class.\n";
}

package Dad;
our @ISA = 'Grandpa';
sub hello {
  my $class = ref $_[0] || $_[0];
  print "Hiya from $class!\n";
}

package Me;
our @ISA = 'Dad';

sub new { bless {} }

sub hello { print "hello\n"; }

package main;

my $me = bless {}, 'Me';         # look Ma, no constructor!
$me->Grandpa::hello;
$me->other::hello;

__END__
How do you do, from Me.
otherwise Me
[download]

hth

I think that:

You think that, but you think wrongly. {grin}

If you have an arrow in your syntax (method call), it respects @ISA (keep searching if subroutine is not found) and unshifts the additional first parameter (class name or instance reference). If you don't have an arrow, you don't get that, because it's an ordinary subroutine call. So those are definitely not the same.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

O Guru,

If the method name is fully-qualified, how could @ISA be used to any effect? When using a fully-qualified method name, doesn't that routine get called regardless of what's in @ISA? (The "other" package isn't in @Me::ISA, in my example above, and yet &other::hello() gets called, and with $me as an argument.)

-- A Humble Grasshopper