On Mon, 18 Sep 2000 13:26:45 -0700, Glenn Linderman wrote:
>> Read RFC 241 for a brief overview of pseudo-hash problems.
>
>I've already read RFC 241. Re-reading in this context results in the following
>comments/quests for information. The remaining quotes here come from RFC 241...
>
>> Doesn't play well with multiple inheritance
>>
>I can sure believe this. There'd be indexes from multiple base classes. I
>don't know how Perl does multiple inheritance anyway, so I can't comment
>effectively on whether this is or would be a problem. If Perl does multiple
>inheritance, I haven't stumbled across the documentation for it, but neither
>have I looked. I don't use multiple inheritance.
If the objects are based upon hashes, then it can be done, provided that
all field names are different for both classes. That is a pretty
unreasonable requirement, because it violates the "information hiding"
principle behind OO: these are details you shoudl'nt need to know.
What happens if one class is based upon a hash, and the other on
pseudo-hash, or an array? Duh...
I have a pretty primitive idea in my head: suppose a Taxi object has
multiple inheritance, it inherits from both a Car and a Driver... So a
Taxi is both a Car and a Driver. But shouldn't you also make this that a
Taxi is a Car that also *contains* a Driver, instead of *being* one?
You can even take this further: that a Taxi is an object that contains
both a Car and a Driver. Poof, out the door go the conflicts...
In order to make this work behind the scenes in OO Perl, multiple
inheritance should automatically call SUPER classes with the *contained*
object of that superclass, not with the object itself. If there's both a
Driver and a Car in a Taxi, Car methods have no need to be messing with
the Driver's properties, anyway...
In my childish enthousiasm, I have the feeling that I've just hit a
jackpot...
--
Bart.
