Daniel Egeberg wrote: > On Wed, Dec 30, 2009 at 01:24, Daniel Kolbo <kolb0057@xxxxxxx> wrote: >> This way multiple inheritance is available for those that legitimately need it [...] > > Could you by any chance provide an example where multiple inheritance > would be required? To be honest, I've never really seen a use for it, > but that may be because I've not used a language that supports > multiple inheritance (not on classes anyway). > In the OP i had an example: >> 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 inheritance. Granted this example has the additional specifications of not having inherited extra properties then needed and not having duplicated code. This example doesn't 'require', multiple inheritance, as we could always just throw all of our code (methods, properties) we would ever possibly conceive of needing into one root class and have all classes extend the root class. So no, there is no example where it would be absolutely required, but i argue the above example legitimates the need for multiple inheritance. Other reasons: If the only way to make your classes follow strict single inheritance is to reduce readability and/or confuse the intuitive understanding of the design's class model structure, then i would argue readable and intuitive code is a legitimate reason (perhaps even a requirement ;) Also, if one is trying to enhance a 3rd party's code, but the 3rd party didn't provide access to the code (closed source) and/or they didn't provide interfaces to allow for mixins. Also, if you don't want to deal with the headache and drawbacks of mixins. Also, if you want to ensure higher levels of code maintainability and so don't want to duplicate code. Also, if you are concerned about your code's efficiency and want to avoid the situation of throwing in all the methods higher up the parent class chain. I think that this list of reasons (specifically maintainability, readability, and efficiency) more than justifies the concern of resolving namespace conflicts. Thanks, dK ` -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
