
Message Passing, Duck Typing, Object Composition, and not Inheritance - mnemonik
http://fitzgeraldnick.com/weblog/39/
======
jtregunna
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.

~~~
joe_the_user
You express the situation quite well here.

Are there _any_ languages that do separate implicit delegation and type
polymorphism?

~~~
ericbb
Go does. See my other comment in this thread:
<http://news.ycombinator.net/item?id=2058963>.

------
timr
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.

~~~
joe_the_user
Indeed.

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.

~~~
timr
_"it seems awkward, fragile and ill-thought-out"_

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.

------
ericbb
Seems a lot like Go (<http://golang.org>).

See <http://golang.org/doc/effective_go.html#interfaces_and_types> and
<http://golang.org/doc/effective_go.html#embedding>.

------
a_strange_guy
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?

------
wccrawford
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.

