in reply to Inheritance can be messy in Perl. Multiple inheritance can be disastrous.
in thread Understanding 'Multiple Inheritance'

Pattern I see repeated over and over is that people who complain about Perl's OO got their notions of what's good OO from programming in other languages. Perl's OO in and of itself is powerful and useful; it's just a matter of grokking the fu (so to speak).

Of course, necessity (perceived or otherwise) being what it is, there are numerous modules out there which seek to give a more rigorous form of OO to Perl - mostly in the Class space. I generally try to make perl's intrinsic OO bits work for me, whenever possible.

Most of the time, I have full control of the class hierarchy, which, as you said, obviates the problem of member name conflicts. Even so, it's possible for things to get hairy; so to head that off, I take the Java approach to multiple inheritance, and stipulate that only one line of inheritance can define member data.

Occasionally, I do use other people's classes which are designed to be subclassed; in such cases, if I need to add member data, I'll go to some extreme in the naming:

package Squatch::Substandard; use Squatch::Standard; use base qw(Squatch::Standard); sub dingies { return $_[0]{'Squatch::Substandard::dingies'} }
Unfortunately, in Perl you're just stuck with everything being in a single hash.
It's true that you only get one scalar (a reference) to bless into objecthood; but it doesn't have to be a hash. And in any case, there's other ways of dealing with this "limitation" than:
to have your hash be two-tiered, with the first level of keys being class names, and the second level being member data for the corresponding class.
And anyway, once you've done that, you're 69% of the way to having extension by aggregation, which (arguably) is a better way to do type extension anyway.
another problem is that unlike C++ and Java which effect this name-spacing at compile time, this solution in Perl does it at run time
That could be said about everything else in perl. If you've drunk the Perl kool-aid, you don't bat an eye at issues like this.
Does anyone know if Perl6 is going to suck less in this regard?
Why don't you read the Perl6 docs and decide for yourself? Your definition of "suck" may be substantially different than a lot of perl users'.
  • Comment on Re: Inheritance can be messy in Perl. Multiple inheritance can be disastrous.
  • Download Code

Replies are listed 'Best First'.
Re^2: Inheritance can be messy in Perl. Multiple inheritance can be disastrous.
by Anonymous Monk on Mar 08, 2005 at 09:39 UTC
    It's true that you only get one scalar (a reference) to bless into objecthood; but it doesn't have to be a hash.
    Indeed, but don't even think for a microsecond that that's a feature. It's not. Try subclassing from the class that uses references to arrays as objects - with a variable amount of data members. Try subclassing from a class that's using blessed closures as objects, and having the need to store instance data as well. Try subclassing from scalar references. Try doing MI from two classes that both use array references as objects - even if you have no instance data to store yourself.

    If you want to play friendly with potential subclassers, you either use references to hashes, or a technique that uses only the reference, and not what's it pointing to, like some fly weight pattern variations, or inside out objects, or Lexical::Attributes.

      If you're trying to do Java programming in Perl, you deserve the pain you get. ;-)
        Obviously, anyone doing MI can't be doing Java programming - as the Java developers succesfully got away by stating "MI isn't needed". And people still love Java.