|
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
Uncle Bob's take on multiple inheritance: Interfaces Considered Harmful
Coincidentally, pretty well my take on it too.
It's a bit old, but I couldn't find a link in here, and thought it may be of some interest.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
It was linked to and debated pretty well at the time.
|
|
|
|
|
Thanks, I did search for it but failed to find any reference.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
PS. Is this the Thread[^] you were talking about?
Because if that's debate you may feel at home in the Houses of Parliament, I didn't see much technical discussion there at all.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Err no. I have the feeling I'm mixing the sites I've discussed this on.
|
|
|
|
|
Interfaces are about contracts, not inheritance.
(i.e. I can use the same screwdriver to fix my computer and my stereo because both implement the "Phillips cross head" interface)
|
|
|
|
|
Nobody (nobody sane anyway) would argue that clear interface between components are not a good thing.
It doesn't excuse failing to implement multiple inheritance though. I've yet to see a cogent argument why they're a bad thing. C++'s implementation is pretty odd, but Eiffel, I think got it much better. At the very least, it would be nice if we had facilities like Mixins, otherwise, as the original essay indicated, we either have to repeat ourselves each time we implement an interface (violating DRY), or we have to choose some other mechanism (violating Separation of Concerns).
But as Pete O'Hanlon pointed out that the debate has already occurred, I won't pursue the matter further.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Debate is generally never a bad thing. I'm all for it.
|
|
|
|
|
I think "Uncle Bob" hit the point very well - there are cases where multiple inheritance really does make things easier, it avoids having to duplicate the code of an interface implementation multiple times. To my mind, a programming language should be about making life easier for the user (programmer) rather than ease of implementation (as long as there is a feasible implementation).
For most languages, however, I think that the fact that polymorphism is implemented through vtables (ultimately inherited from Simula, but usually more directly from C++) is the sticking point. Laying out vtables for multiple inheritance isn't too tricky, but usually involves some kind of pointer manipulation when casting pointers. C++'s solution is kind of horrible when you look at the technical details.
However, Eiffel comes up with an entirely different solution, which actually isn't that different from that used by Self (a dynamically-typed Smalltalk-like language that introduced the idea of prototype-based inheritance). With this scheme, rather than using vtables, polymorphism is implemented by, at the worst case, some kind of lookup. In the worst case, this results in worse performance than C++, but as Self illustrated (influencing pretty well all later VMs including Java, .NET and VM) it is possible to optimise the common paths, often resulting in the called function effectively being included inline at the call site (that's the essence of HotSpot compilation - which is exactly why Sun bought in many of the Self team to work on the Java VM).
In .NET, the closest to a solution is extension methods. However, unlike polymorphic calls these are statically bound and cannot be overridden, so are much more limited. Given the nature of the VM, I think the best we can hope for here is some kind of mixin-based implementation.
Mixins give many of the good features of Haskell typeclasses. One of the best examples there is the Comparable type class, which (in C# terminology) provides default implementations of most of the methods - if you provide one method, you get the others for free, so defining "<" for a type allows the system to infer the rest (of course, you can still implement these if you can find a better implementation).
To my mind, though, at essence it simply comes down to finding solutions which make it easier for a programmer to write correct code. Single inheritance limits the space of available solutions, and having used languages with multiple inheritance, I frequently find it frustrating having to repeat boilerplate code in a number of classes - a process which is more likely to produce errors, especially if you omit one of the cases during maintenance.
Of course, all this doesn't obviate the usefulness of interfaces as a design concept - it is a very good idea to have clearly defined interfaces between components. I just feel that interfaces (as in C# and Java) mix this concept with a limited form of multiple inheritance.
I'm very hopeful C++ concepts will be closer to my idea of this, than the C#/Java model. Rust also has some promise in this area. Traits in Rust are like both Concepts and Interfaces, but allow for default method implementations much like I discussed above for Comparable.
(Wow, that was a bit of diatribe).
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I rather suspect that the issue isn't so much that interfaces are bad it's that there's discontent that multiple-inheritance isn't present. The interface-as-a-contract argument is a powerful one and it's an incredibly useful construct, especially for things like IoC. The diamond inheritance issue, is a real issue but it could have been tackled in any number of ways. Saying that, I don't use inheritance that often anymore - I tend to find that I use composition a lot more, which somewhat negates the need for inheritance chains.
|
|
|
|
|
What would be interesting (which, BTW, I've suggested to the C# folks -- who rejected the notion outright) is what I would call "interface delegation". You could have an interface on a class that was implemented by a data member of that class. A la:
class Foo : iObservable implementedby myObservable
{
ObservableImpl myObservable;
}
or some such (maybe an attribute on the data member).
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
That's exactly how Self managed delegation. No inheritance needed at all (or classes).
To paraphrase in more C-like syntax...
Comparable = { ... }
Cloneable = { ... }
myObj = {
parent compare = Comparable;
parent clone = Cloneable;
}
Then any messages sent to myObj not handled directly are passed to Comparable and Cloneable.
Much better example of prototype-based inheritance than JavaScript, which I think turned many people off the idea by implementing it so badly.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Interesting, but it seems like the parent specifier denotes a sort of "inheritance", so that contradicts your "No inheritance needed". Ah, you do mention this is a kind of prototype inheritance.
Very interesting.
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
Indeed, I wish Self had had more adoption - and a Windows implementation would be nice too.
The most influential language no one has ever heard of. It was a Smalltalk-like language, with prototype-based inheritance (delegation), and a VM that was the forerunner of techniques used in just about every modern language VM, but seems to have passed under the radar of almost everyone.
I suspect the Smalltalk-like syntax was just too alien for most people.
The following video gives some idea just how far ahead of the curve it was: Self Video[^]
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Interesting. Thanks. Though most of the video wasn't really about Self itself, but what was happening around Self. The first half could be skipped without any loss.
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
I've found http://www.selflanguage.org/[^] which is the home page for the Self language. Which points to the github repository. Looks like the last activity was about 2 years ago.
I may have found something to do in my vast amounts of "spare time".
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
|
sigh
If he's so bothered by the semantic difference between interface and class, then why doesn't he advocate for a number type instead of int and float?
|
|
|
|
|
Maybe because they have semantic differences.
For a better approach, look at type classes in Haskell, where there is indeed a Num type, as well as an Integer type and a Real type (with implementations as both Float and Fraction).
Note, however, that a type class can include default implementations of functions, and its power begins to shine.
Great straw man argument though.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Don't take my post the wrong way. I actually think it's silly that C#/Java doesn't have real multiple inheritance. But even if they did add that to those languages, I think Interfaces should remain, as they have significant semantic meaning over "abstract class" which seems to be Uncle Bob's argument: interfaces and abstract classes are the same thing, so why have interfaces?
|
|
|
|
|
Vark111 wrote: I think Interfaces should remain, as they have significant semantic meaning over "abstract class"
Agreed.
Vark111 wrote: Uncle Bob's argument
Is really about the lack of multiple inheritance.
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
I don't see a significant difference in the presence of multiple inheritance.
I see a use for interfaces between components, obviously, but why can't that interface:
- Be an abstract class, possibly distinguished by naming convention.
- Even provide default methods (as LINQ works around using Extension Methods).
Haskell's Type Classes manage the second form very well. Eiffel manages both.
Effectively, as a language feature, interfaces only offer limitations, not features.
As a design feature, they are essential.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I don't agree that interfaces are harmful. What I get from his "essay" is that not being able to have multiple base classes is what is harmful. I agree, however, that an abstract base class with only non-implemented abstract functions is equivalent to an interface. Which means interfaces are superfluous.
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
modified 23-Jun-15 16:27pm.
|
|
|
|
|
Absolutely agree, it would be silly to design software without the idea of an interface between components, but in the presence of multiple inheritance, they can just be a naming convention.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
