Property vs Behavior inheritance

Axel Rauschmayer axel at
Thu Dec 15 09:51:13 PST 2011

[[Prototype]] -----> [[Prototype]] ------> [[Prototype]] -------> null
myProps           |  parentProps           grandProps
[[Prototype]] ----+

> But once we use these classes to create instances, those instances will very likely have data. Thus they will no longer be effective as 'classes'.

True this phenomenon often shows up in pre-ES5 code, as an anti-pattern:
Sub.prototype = new Super();

> In real JS code there is no way to tell if an object is intended to be a class. Objects that implement useful behavior seem like great candidates for "prototypical inheritance".  This burns every JS developer at one time or another. And probably much more than most will admit.

But do you ever extend myProps? You have to be acutely aware of what is going on, anyway, otherwise you will wire up things incorrectly.

> Classless solutions need a compelling solution to this issue, that is, an operation on a list of vanilla objects that yields a class-like object. Any such operation will fail in some cases, just like class-based solutions fail sometimes (when you really want to share data across classes). But a solution is needed for the 99% of the time when you don't want data sharing.

A naming convention is not enough? Right now that works reasonably well for “functions versus constructors”. With object exemplars, you have:

    var jane = new Person("Jane");
    var Employee = Person <| { ... };

I don’t think one would make the mistake of extending jane. Ironically, a class-based mindset works well here and does not lead you astray.

Dr. Axel Rauschmayer
axel at


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list