in reply to Skipping the middle man & the SUPER gotcha

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.

--
brian d foy <brian@stonehenge.com>
  • 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 tlm (Prior) on Apr 02, 2005 at 21:29 UTC

    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

[reply]
[d/l]
[reply]

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

        Ah, of course, that make a lot of sense.

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

        I'm still scratching my head about this one. This is partly because I have not yet fully grokked Class::Prototyped (but I'm getting there :-) ), but partly because for the longest time I thougth that by "wrong" you meant bad OO design (and for the life of me I couldn't, and still can't, think of any scenario in which it would be OK design-wise to use $me->Dad::hello() but at the same time not OK to use $me->SUPER::hello()). Then it finally hit me that (maybe!) by "wrong" you meant "semantically wrong", as when the code in package main contains the expression $me->SUPER::hello() intending to access the hello method of $me's parent class. With "package-less classes" as those created with Class::Prototyped, there would not be any scope in which the SUPER pseudo-class had the desired meaning.

        So at least that explains (maybe) why SUPER is particularly problematic with classes/prototypes created with Class::Protoyped. But what I still can't understand is how the fact that Perl allows the $object->ParentClass::method() form can be of any help if such a class wanted to invoke a method in a parent class. For example (adapted from the Class::Prototyped docs): 

            use strict;
    use Class::Prototyped ':EZACCESS';

    my $Dad = Class::Prototyped->new(
      hello => sub { print "Hiya from $Dad!\n" }
    );

    my $Me = Class::Prototyped::new(
      'parent*' => $Dad
      hello
        => sub { # ???
                 print "I'm just a WILD AND CRAZY GUY!\n";
               }
    );

        [download]
        How can anything having the form $object->ParentClass::method() be used the definition of $Me's hello?

        the lowliest monk

[reply]
[d/l]
[select]

      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.

[reply]
        Exactly. I think when someone says something is 'wrong' (at least in a Perl context, maybe not so for other languages) they mean 'wrong in 99.999% of cases'. If you happen to be in the 0.001% of the world where it's not wrong (or at least not completely wrong), then I hope you're using Perl :)
[reply]

In Section Meditations