You knew someone was going to reply from the P6 aspect, right? Please tell me you did! :-)
Sorry, but no I didn't know. I thought someone might though:)
Each class can be written with that in mind or they can just handle it and be selfish.
In the first case, all the co-inheriters (and by extension, all possible co-inheritors, which is another way of saying: "every class that ever might be inherited from.") have to consider the possibility, and handle it.
In the second case, you have to add a mechanism to the language to allow the superclass writer to hand code the inheritance/dispatch ordering. But do you do that:
When would you do this? The only obvious place is with in an superclass override of the dynamically order submethod--but then what did the MI buy you that composition wouldn't?
In any case, I think that roles (if they turn out to be what I think they should be) will obviate the need for the above manually controllable dispatch ordering and render MI a little used feature.
The real problem with the CD player / Radio example is a that the problem was ill-conceived.
However, I did know that this objection would come up :)
The problem is that hindsight is 20:20, but you can neither buy it, nor be taught it--nor inherit it:). You can only acquire it with time, and by then it is too late.
When the radio was invented, the CD wasn't even Sci-Fi material. And yes, I know I have stretched the analogy too far, but it does hold.
In order for your sub-elemental design to work, you need to have the entire problem laid out up-front--or spend an inordinate amount of time speculating what the future might hold.
Taking the analogy a little further. You've designed and implemented your componentised system. It works great. Then you get the requirement legislated upon you to support a new technology that turns sound into 'pictures' that the deaf can 'hear'.
The problem is that 'tone' controls for this technology need to mix components of both the left and right audio channels according to a bizarre (in audio terms) function so that the tone control varies the definition of the 'picture' in a 3-dimensional way. Further, the volume control needs to vary the range of colours in which the overall 'picture' is presented in. But, because deaf people also suffer the same visual maladies that other sighted people suffer--colour-blindness; short-sightedness etc.--it also becomes necessary to be able to limit the range of colours over which the volume is spread to some sub-range of the total possible to ensure they remain within the visual accuity of the user.
That is Sci-Fi as far as I am aware, but the point is that there is no way to know now, when that requirement will become a reality, or what constraints and requirements it will impose upon existing systems. Trying to define your componentisation now, such that it will allow for their inheritable inclusion into that (and all other) future systems is an impossible task. So don't try!
Design you system, and it's components to deal with todays requirements and realities--and no more. That allows you to keep it as clean and light as is practible now. It may mean that a future system that incorporates it (through composition) will be more bulky and need to actively override (rather than pass through) more elements than might otherwise be the case had you been able to design with that new system in mind.
But it also means that all the other uses of it without those special ancillary requirements did not have to bear the costs of the speculative possibilities.
If the composite system with the special requirements proves to be too heavy, inefficient or laborious, then the subsystems it uses will need to be reworked or re-designed from scratch with the new requirements in mind, but either way, the rework will now know what those new requirements are, and will be able to make specific decisions based upon them.
Any speculative extras added into the original design might preclude that re-working, but then again, they may not. And history favours the latter. In that case, all those speculative extras in the original design simply burdened all the uses of that design that didn't use them, and all the design and implementation that went into them was wasted. Indeed, it may well be that it was the very presence of those extras that forced the re-working.
Designing your 70's TV with a press-out slot for a Beta-Max video tape may have seemed like a good bet at the time, but ultimately would have been a bad decision :)
In reply to Re^5: Understanding 'Multiple Inheritance' (hindsight)
by BrowserUk
in thread Understanding 'Multiple Inheritance'
by punkish
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |