You really should check out functional programming languages based on your comment on favoring composition over inheritance. (besides that, it is ideal for both very large and very small scale programs, and everything in between) Modern functional languages, such as Haskell have very sophisticated ways of dealing with polymorphic types, and good module systems, and make composition very central to coding practice. In Haskell’s case, they separate I/O from functions (by using the I/O Monad), which ensures that function composition remains pure in every case. If you just want some mix of higher order functions and mixed OO techniques, Scala is complex, but might suit your needs. (plus, it’s on the JVM if you’re a java programmer)

If I remember correctly, Objective C has delegation built in. You can say, If you don’t find the requested method in me, try this other object.

The “ideal” object-oriented design has objects speaking to each other only through known interfaces (with the generic “send message” method being an assumed universal amongst all objects). It’s the whole “programming by contract” argument.

Unfortunately, the C++ designers (or whomever they were borrowing it from) were very implementation-focused and gave us *inheritance*. It worked well (i.e. computationally efficient) to have a “base class”, etc. But a better solution would be to have only interfaces (contracts).

With the curly-brace languages, you can certainly practice a pure-interface approach with your own class libraries. The pain and suffering is in shared implementations. A huge percentage of the time when you have sub-types you want to suck in the implementation for part of an interface that’s common with the parent type. Inheritance does this (and implies an interface), but it’s a sledgehammer.

If curly-brace languages had the native notion of *composition*, not just containment, we’d be in business. I can’t remember which language I was working in at the time, but I seriously pushed hard on introducing composition syntax:

The above should be pretty obvious, with the suggested line translating to “forward all method calls on MyObject that are defined by the IReadWriteXml interface to _xmlParser.” Instead, we have to do this:

And that’s just a trivial example. This is exactly the kind of boiler plate code that higher level languages are supposed to eliminate.

Multiple prototypes (instead of classes) is another solution, though less precise because it wouldn’t specify which interfaces should be forwarded to which prototype objects. And I don’t know if any languages are multi-prototype.

As you can see, I’ve been thinking about this language nuisance for damn near a decade, and I know I’m not the only one. Almost every good, data-driven system I’ve code has this very feature, even if only implicitly. Composition is king (for all the reasons you stated) — inheritance is a crutch, a necessary evil, not because it solves problems at the computer science level, but because it solves problems at the implementation level, and only because of the constraints our tools invented and enforce!

So, is it feasible? Yes. Would you be making some things harder, probably. Anyway, this is the first I’ve heard of Noop, I will have to check it out. And thanks for the interesting post.