class sugar

Christopher M. Balz christophermbalz at
Sun Jun 5 19:50:33 PDT 2011

Are there proposals for fixing, without going as far as making a 'class' system, the major drawback of prototype-based inheritance: Without something like a JavaScript (js) class factory (a class factory as provided by most js frameworks) to provide inheriting instances their own copies of mutables (objects, as distinguished from immutables such as strings, numbers, and functions), all inherited mutables are always shared by all inheriting instances, even when modified by a single inheriting instance.  The problem does not exist with immutables, as unique copies are bestowed upon an inheriting instance (as I understand it) if and when it modifies the property.

Also, without going so far as making a 'class' system, are there proposals for fixing these limitations: The confusing 'constructor' property value, the inability of 'this' properties to be private (we can do privates now with a closure, of course, but they are not inherited along the prototype chain), and the limited reflective capabilities of JavaScript.  

Regarding the latter, in my development workgroups (engineers using JavaScript in collaborative teams to build Web-based applications), using 'this.$DATATYPE' (obviously, when using a class factory) has been popular as it aids with practical development velocity.  The '$' makes the property name float to the upper segment of the relevant list in the debugger, so the developer can quickly glance to see what kind of object s/he is currently stopped in.  However, I'm asking about a built-in way to do the same thing, and without classes (e.g., 'this.$NAME').  

In the JavaScript frameworks I've done and worked on, 'class' has been very practical as almost all developers can easily understand it and it does not surprise them with hard-to-fix bugs related to shared object properties from the prototype chain.  But that fact is due to the dominance of Java and C++ in the scholastic curriculum and industry.  As JavaScript gains the surprising dominance and pervasiveness we see today, perhaps the need for 'class' has diminished now.  Additionally, if I may offer an anecdotal impression, the general JavaScript user community has become quite sophisticated about JavaScript and I hear many developers wanting to stick with plain prototypes, apparently for this aim of simplicity. 

Summing up, it seems that adding 'class', while very helpful for the vast majority of developers who have been trained in Java and C++, does stray far from the original intent of simplicity of what I understand to be one of the inspirations for JavaScript, 'Self' (e.g., "Self: The Power of Simplicity",   And the center of gravity may have shifted toward JavaScript enough that 'class' may no longer be as needed by the user community as it was even a couple years ago.  So I think it would be better if 'class' could be avoided and instead, the few drawbacks I mention above fixed with some choice keywords (for example, a keyword to mark a mutable (object) property of a prototype instance such that inheriting instances would get their own unique copies of it).  That would enable many or most of the benefits of a 'class' system, while preserving the simplicity of the unity of type and instance that was
one of the original selling points of 'Self'.  

   - cb
From: Allen Wirfs-Brock <allen at>
To: Peter Michaux <petermichaux at>
Cc: es-discuss <es-discuss at>
Sent: Saturday, June 4, 2011 12:38 PM
Subject: Re: class sugar

On Jun 3, 2011, at 9:43 PM, Peter Michaux wrote:

>closure-based system ----------------------------------
>function makePoint(x, y) {
>   return {
>       getDistance: function() {
>           return Math.sqrt(x * x + y * y);
>       }
>   };
>The classes strawman is proposing terse syntax to make the
>new/prototype/this-based system more aesthetic.
>Introducing class syntax will be one of the most monumental changes
>ever made to ECMAScript and I suggest that unfortunately the proposal
>is targeting the wrong version of creating constructors. I've found
>the closure-based system more compelling than the
>new/prototype/this-based system. My memory even makes me think that
>this list was heading in the direction of sugaring the closure-based
>system in 2008.
>Was using class syntax to sugar the closure-based system thrown out as
>a possibility for some reason?

Note that the enhanced object literal proposals that were also promoted  significantly enhance what can be expressed by an object literal used in the closure pattern:

const pointProto = { /* shared methods that don't use closure captured state */}

function makePoint(x, y) {
   return pointProto <| {
       getDistance() {   //getDistance is a non-enumerable property, like methods should be
           return Math.sqrt(x * x + y * y);

es-discuss mailing list
es-discuss at

More information about the es-discuss mailing list