Extended Object Literals to review

Allen Wirfs-Brock allen at wirfs-brock.com
Sat Mar 12 08:25:15 PST 2011

On Mar 12, 2011, at 6:04 AM, Juan Ignacio Dopazo wrote:

> Hi! I hope you don't mind a couple of questions about this proposal.
> The <superclass> meta property definition says:
> This causes the [[Prototype]] value of the new class’ prototype to be set to the prototype property value of the designated constructor function
> Shouldn't the superclass' prototype be chained with the class' constructor prototype instead of replacing it, as in Douglas Crockford's prototypal inheritance article? I believe this is easier to understand and less error prone, because when modifying properties in the new class prototype they won't be added to the superclass' prototype.

I think I many not have been clear enough.  In my proposal the follow two class initialisers mean exactly the same same:

class c {
   <proto: s.prototype>

class c {
   <superclass: s>

both are equivalent to:

function c() {};

proto: is the most general form, superclass: is provided as a convenience and to push non-essential details of ECMAScript prototypical inheritance into the background for the most common use cases.

> Why were class bodies chosen as object initializers instead of function bodies?

In order to provide a declarative form  for the conventional constructor/prototype/instance "class" definition pattern.  In a declarative form you (or an implementation) can determine the initial "shape" of the objects (the complete set of properties) without having to either simulate  execution of the constructor or wait until runtime and observe actual execution of the constructor.  This makes the original programmers intent clearer for future readers and maintainers of the code, it enables software tooling, and opens the door for optimizations that might not otherwise had been performed.

> Function bodies allow for a couple of good concepts such as defining private variables by default with the var statement, avoiding the use of the this keyword for private variables and thus producing shorter code when minified.

But their main problem is that they cannot be understood without either simulated or actual evaluation and in the worse cases their results will differ from evaluation to evaluation.  

Nothing has been taken away, you can continue to use closure capture if you wish, with or without using the extended objects or class initilisers.  Closure captured variables are a distinct concept and have different semantics and optimization characteristics than  properties.

I'll concede on the minification argument.  I don't think it should be a primary concern in driving this sort of design.  Also this.foo and foo semantically mean quite different things.  I want both.

> Also, what happens to methods in these proposal? Are they defined as properties of the instance or as part of the prototype? If they are fresh instance properties, is there a method for defining prototype methods when using the <superclass> meta property?

quote from the wiki page:

The body of a class initialiser is quite different from that of a function. The bracketed body of a Class Initializer is essentially an extended object initialiser rather than a function body. Except as elaborated below, the properties defined in the object initiliser are created as properties of the prototype. For example: 

I guess I should at that emphasis to the wiki page.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110312/a26afd36/attachment.html>

More information about the es-discuss mailing list