Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re: Re: •Re: RFC: Class::DispatchToAll

by dws (Chancellor)
on Jul 11, 2002 at 06:03 UTC ( #180954=note: print w/replies, xml ) Need Help??

in reply to Re: •Re: RFC: Class::DispatchToAll
in thread RFC: Class::DispatchToAll

The problem this solves is very real-world. Consider a Perl class hierarchy in which a class Child inherits from classes Mother and Father:

Uh, oh. Multiple Inheritance.

A couple of years of doing Smalltalk (which didn't have multiple inheritance, but which let you fake interface interitance via mixins), and a couple of years of Java and C++ have lead me to believe that Multiple Inheritance is a Very Risky Thing, and that it can always be worked around by either composition or reducing to inheriting from one data-bearing class and multiple (data-less) interface classes. Doing so avoids the multiple destructor problem.

Perhaps you've run into a situation where multiple inheritance is the right thing to do. If so, I'd like to hear about it.

  • Comment on Re: Re: •Re: RFC: Class::DispatchToAll

Replies are listed 'Best First'.
Re: RFC: Class::DispatchToAll
by Abigail-II (Bishop) on Jul 11, 2002 at 11:07 UTC
    It happens often in LPC. It's a language mostly used for building MUDs. Often you will have a standard weapon class and a standard wearable class. All weapons inherit from the weapon class, while all wearables inherit from the wearable class. But boxing gloves would inherit from both.

    Some problems LPC has with multiple inheritance aren't found in Perl (for instance, the possibility of duplicating variables when a class is inherited by two paths - different implementations of LPC solve it differently). Other things are solved differently, for instance, one flavour of LPC forbids inheriting from two classes if they have methods with the same name - unless the inheriting class defines a method with that same name.

    There is nothing wrong with multiple inheritance. It's just hard to implement is right, which is way some languages take the easy way out and outright forbid it. Inheritance is already a hard problem in Perl, but multiple inheritance is a real nightmare. But that's the fault of Perl, not of multiple inheritance.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://180954]
[stevieb]: ask a question on SoPW, and include at least a half-dozen examples of the input, and at least one example of expected output
[davido]: Exactly: SoPW. This isn't going to be solved easily in the CB.
[james28909]: in need "yesterday" and so on, to be absolute like "1" or "31"
[stevieb]: ...and throw some of your existing code into the equation as well, just so readers know you've given a try at it ;)
[james28909]: ok
[stevieb]: davido thanks for the link ;) I was being the typical lazy
[davido]: date parsing is hard. The more examples you can provide of the input (within reason) and expected output, the better.
[stevieb]: agreed. That's why I said at least a half-dozen. If enough of the different formats are present, the date/time folk may not have to request more. If they do, then at least there was a decent base to start with
[stevieb]: I do date and time transformations in both Perl and Python, but not frequently enough to not have to search for the format params etc ;)

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (3)
As of 2017-04-29 02:40 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (531 votes). Check out past polls.