Inheritance is two language features in one though—It's implicit delegation and type polymorphism. Those two features need not be coupled together like that, and in fact, shouldn't in my opinion. It's not that silly things can be done with inheritance, it's more that people often use inheritance for one of two things, but rarely both: implicit delegation and type polymorphism. Pick your poison, and use the appropriate construct. I'm no fan of implicit delegation when I can get away with not having to deal with it, but I wish more languages would have an orthogonal construct for type polymorphism separate from inheritance.
As mentioned by ericbb, there is Go, yes. I've been working on another; a prototype based OO language without inheritance, explicit delegation and type polymorphism, but have nothing I want to show just yet.
Sometimes, inheritance is the right tool for the job.
Sometimes, composition is the right tool for the job.
Sometimes, duck typing is the right tool for the job.
The only valid absolute is that bloggers that insist otherwise are wrong.
I recently replaced a containment relationship with an inheritance relationship.
Sometimes inheritance does make sense yet despite it being the least-bad "tool for the job", it seems awkward, fragile and ill-thought-out. You have some attributes hidden in the parent and attributes right there in the child. The idea that the ontological relationships "is-a", "has-a" etc should map cleanly to the class as buckets-of-functions-and-attributes isn't always correct and muddies the water IMHO.
I wish that there was something that worked like inheritance but was better. Perhaps a system of passing interfaces from objects to the object they contain would make things clearer and more flexible.
Or, you know...not. Sometimes, inheritance is the perfect abstraction for the job, neither awkward nor fragile, but perfectly elegant. Which was my point.
When you've got an is-a relationship, inheritance often makes sense, and encapsulation is frequently awkward. When you've got a has-a relationship, inheritance is frequently awkward. Just because you can find an awkward use of inheritance or a leaky abstraction doesn't mean that inheritance is awkward. It's a tool with limitations, and the world is a messy place. Containment isn't a magic bullet, either.
I honestly don't understand where the bias against concepts comes from. When the concept works, you use it. When it doesn't, you don't. It's engineering, not religion.
What I still don't get is why inheritance in OO-languages is always the heavyweight version, namely subclassing.
Imho every class definition in Java-like OO languages should create two types: A (by default) public interface and a (by default) private class.
When you want to inherit from something you should then be able to choose if you want to inherit only the interface or inherit from the full class. Every good design already separates interface from implementation, so why isn't it enforced at the object system layer?
I've been hearing some disdain for inheritance lately for some reason. This article is filled with it. For instance:
"The beauty here is that you can reuse code without dealing with inheritance, or any sort of class-based hierarchy."
... That's the beauty? The only beauty if that you managed to avoid a feature of the language? Ouch.
I get that really dumb things can be done with inheritance, but that's true for almost any language feature. It's certainly no reason to avoid it altogether.
