Eric Elliott — do you agree?
Scott Molinari

He and I have been through this before, and I can guarantee you he won’t agree. But you can take a look at some of the past discussions for insights. The part that interested me — and seems to equally surprise even Elliott’s most faithful readers — is that class A extends B {}, even in an unambiguously classical language such as C++, is — according to Eric Elliott — object composition. On the other hand, if I write a = stampit.compose(b) and c = stampit.compose(a), then that — according to Eric Elliott — is class inheritance, even with stamps. It turns out class/extends isn’t inherently bad, nor stampit/compose inherently good. It depends entirely on how you use it. For all his blog posts, it turns out Elliott’s rules are actually pretty simple: 1) Don’t inherit more than one level deep, and 2) Don’t override anything. Essentially he’s offering suggested best practices for when using inheritance. If you use inheritance according to his rules, then he calls that object composition. If you use inheritance but violate those rules, only then does he call that class inheritance.

Problem is, that’s not what the rest of the world calls object composition, and even if you follow those rules, you’re still not “favoring composition”. You’re still using inheritance.

Herb Sutter (the #2 guy in the C++ community) describes composition as “embedding a member variable of a type within another type.”

The GoF book — where the rule favor composition over inheritance comes from — describes object composition as “objects acquiring references to other objects,” and the code examples in the GoF book exactly match that and Sutter’s description.

The Python community describes composition that same way.

The ActionScript community (ActionScript is an ECMAScript language) describes composition that same way.

MDN describes composition that same way.

Even Wikipedia describes composition that same way.