in reply to Skipping the middle man & the SUPER gotcha

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

  • Comment on Re: Skipping the middle man & the SUPER gotcha

Replies are listed 'Best First'.
Re^2: Skipping the middle man & the SUPER gotcha
by merlyn (Sage) on Apr 02, 2005 at 16:20 UTC
    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.

[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

[reply]
[d/l]
[reply]
      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 :-)

[reply]

In Section Meditations