Larry Garfield wrote: > On Monday 28 December 2009 9:45:03 pm Daniel Kolbo wrote: >> Hello, >> >> Okay so PHP designers explicitly decided against multiple inheritances, >> but aren't there legitimate needs for multiple inheritance in OOP? >> >> For example, consider the following three classes (A,B,C) with the >> following properties (a number is a distinct property or method). >> >> A: 1, 2, 3 >> B: 1, 3 >> C: 1, 2, >> >> I would like to set the 3 classes up so that no object has 'extra' >> properties than it requires, so that no property has to be >> declared/defined in two or more classes, and so that we are strictly >> using single inhertiance. I don't think it's possible. I've been >> incorrect beforee...If i'm incorrect please let me know how to set this >> up as a single inhertance class structure. >> >> If this is not possible, why doesn't the PHP community implement >> multiple inheritance? (I'm anticipating that someone will say, you >> simply need to redefine what you are calling your objects so that the >> properties do permit a single inheritance...) >> >> I'm very interested to hear why there is the dogma of single inheritance >> only. >> >> Thanks, >> dK >> ` > > Because pure multiple inheritance can lead to all sorts of highly weird > behavior when you don't know which parent class you mean at any given time. > Single inheritance is just easier to wrap your head around, and wrap the > compiler's head around. > > What you're looking for is composition, which can do pretty much what you're > looking for. See my last reply to you on this list from Christmas day. > > There's been some discussion of implementing "traits" in later versions of > PHP, but no concrete patches so far. > Hello Mr. Garfield, I saw your reply on how to mimic composition, and I appreciate your comments. I don't prefer (not saying that anyone really does) the mixin approach as private/protected aspects of the mixined class are not available in the pseudo-child class. Also, the code may still need to be maintained in the child class for some changes in the parent class. I would prefer to throw too much into my parent class then to deal with the mixin approach (at this time). I understand about a seemingly simple idea, being not so simple to implement. However ;), for name conflict issues, the compiler could have a simple rule. Such a proposed rule might be for the compiler to throw a warning and to use the last definition supplied. This way multiple inheritance is available for those that legitimately need it and the warning is there so the 'spooky' behaviour scenario can be isolated to an hesitance name conflict. I was reading the request for comments about the traits. My thought is, if we go through the work of allowing horizontal reuse into php, why not do the work for multiple inheritance first. I could understand having the default install to only single inheritance, but i do not understand why php programmers are not, at least, given the option. Thanks, dK ` -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
