Re^5: Understanding 'Multiple Inheritance' (hindsight)

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:

Once for all the classes from which you are inheriting?
Once per coexistant method, so that you can prefer some methods from one subclass and others from another (or several others)?
Dynamically as the state of the superclass changes?
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 :)

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

Comment on Re^5: Understanding 'Multiple Inheritance' (hindsight)

Replies are listed 'Best First'.
Re^6: Understanding 'Multiple Inheritance' by dragonchild (Archbishop) on Mar 07, 2005 at 14:53 UTC
Except my system already handles that. You have an output system that is pipelined with the music-maker and the controls. The controls will say to the speakers "Please increase the volume from 5 to 6". The music-maker will say to the speakers "Please output the following sounds". The speakers will then do what they feel is appropriate with what they receive. Pictures, sound, smells ... I don't care. The pipeline has done what it was supposed to do - pass requests back and forth. Now, it may be appropriate to create an aggregate class to deal with the speakers. But, that aggregate class will conform to the same API as a standard speaker, so it's a drop-in replacement - a plug-in, so to speak. Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.	[reply]
Re^7: Understanding 'Multiple Inheritance' by BrowserUk (Patriarch) on Mar 07, 2005 at 15:14 UTC
But what-if the 'visual speakers' need to feed-back to the MusicMaker to say "Don't feed me any high-frequency components, because the user is in bright sunlight and their definition is lost, so instead, spread the frequencies below this cutoff level over the full range"? Don't take that too literally, I ain't an audio-visual engineer, it probably makes no sense at all. But the point is, you cannot predict what the future requirements may be, nor what vertical splits in the overall architecture will makes sense when the future arrives. It made no sense to use separate subsytems when they made the big valve driven "wireless" set that I remember from my childhood home. And I remember when my father saw his first "separate subsytem stereo", (deck, amp, tuner, eq etc.)--my sister got it for her birthday--he offered to build her a nice all-in-one wooden cabinet to hold it :). (Does anyone remember the early 80's UK TV ad. for a Sony audio system with John Cleese? The separates came with a stand-alone cabinet with a smoked glass door, and the catch-phrase was something like "Hides all that spagetti hanging out the back!") Predicting the future is a very inexact science. Examine what is said, not who speaks. Silence betokens consent. Love the truth but pardon error.	[reply]
Re^6: Understanding 'Multiple Inheritance' (hindsight) by punkish (Priest) on Mar 07, 2005 at 15:22 UTC
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'. speakseeing of which... SoundOfAnImage -- when small people start casting long shadows, it is time to go to bed	[reply]
Re^6: Understanding 'Multiple Inheritance' (hindsight) by dragonchild (Archbishop) on Mar 07, 2005 at 17:20 UTC
I wanted to reply to the issues you raised with P6's handling of multimethod dispatch. In the first case, all the co-inheriters . . . have to consider the possibility, and handle it. Actually, they don't. There will be a usable set of default behaviors. And, just like in all things, you only have to define something if you don't like the default. If you like it, don't redefine it! (As an aside, I wish people would follow this advice for most overloaded stuff. If you have a random numeric overloaded object that doesn't subtract when adding or some other goofiness, just define numify, set fallback to true, and let Perl handle the rest.) you have to add a mechanism to the language to allow the superclass writer to hand code the inheritance/dispatch ordering. And, since Larry wants it, Larry's gonna get it. Re-read A12 for how he will do this. The short version is you'll get to do it in all the places you mention, and more. 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. Absolutely! There will be little need for MI at all, once roles/traits/mixins/etc/etc/ad-nauseum are grokked. But! (and there's always a but) . . . in those random cases where MI is actually the easier WTDI, then you will have the option. Remember - roles/traits/whatever are really a generalization of multiple inheritance without all the bagage that MI comes with through single inheritance. Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.	[reply]
Re^7: Understanding 'Multiple Inheritance' (hindsight) by BrowserUk (Patriarch) on Mar 07, 2005 at 18:21 UTC
In the first case, all the co-inheriters . . . have to consider the possibility, and handle it. Actually, they don't.... What I mean by that is; say you have a method that has two effects upon the current state of the object. For simplicity we'll say that the foo() method increments or decrements a variable dependant upon it's parameters, and left-truncates a string. A superclass comes along and wants alter the points at which the variable is incremented and decremented, but it cannot easily do so independantly of the truncation because if it overrides the class and doesn't call the supermethod, the truncation doesn't happen. If it does call the supermethod, it looses control of the variable setting. "Oh, but the two actions should be independantly overidable!", I hear someone say. Except, that when the class is written, there is no reason for that. Also, the two actions are inextricably linked. When you do first, you have to do the second, and you cannot do either without the other. Making them independant methods and having one call the other every time works, but only if you have the knowledge or foresight to predict the breakpoints within overall actions required by the original class that might be useful in a superclass. In extremis, this would require every independant function, statement and clause of every line of every method to be rendered as it's own independant method. In effect, you would need to be able to override every opcode independantly. This is obviously ludicrous as 99% of them will never be overridden. And that's the point. No matter how you decide to override the requirements of the current need to cater for "future possibilities", you may make--are quite likely to make--the wrong choices. And so your attempts fail to help future developments and may even hinder them. The alternative is that you make no such concessions to the future and code just that which is required. When the future arrives and the requirements are known, then the base class may need modifying, but in the mean time you have saved costs by avoiding unnecessary effort, and probably simplified the tasks of all those applications that use the original base class with having to cater for those unnecessary future requirements. When the original base class is modified to meet those future requirements, it may impose changes on existing users also, but at least you will know that they are required. If you attempt to predict the future requirements and cater to them now, in order to minimise change in the future, it makes you vulnerable to making the wrong choices, which Sod's Law says will happen greater than 50% of the time. Examine what is said, not who speaks. Silence betokens consent. Love the truth but pardon error.	[reply]