extends keyword instead of <superclass ... >

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Mar 28 20:54:55 PDT 2011

On Mar 28, 2011, at 5:36 PM, Brendan Eich wrote:

> On Mar 28, 2011, at 12:29 PM, Allen Wirfs-Brock wrote:
>> That is why in my proposal
>>    class Foo {};
>> is defined to mean almost exactly the same thing as
>>    function Foo() {};
>> (but things start to change when you put something between the brackets) and anonymous classes exist as an analog to function expressions.
> Is the non-empty braced body an initialiser (extended) or a constructor code body? I'm on record against the initialiser extension for precisely this reason: function has a code body.

In my current proposal it's closer to an initialiser than a function body although it really isn't either.  We really want a class body to be mostly declarative (that the compiler can optimize)  rather than using imperative statements to construct the instances. 

But we may be thinking about different kinds of optimizations.  I'm thinking of predetermining the "shape" of the instances.

>>> More substantive: if we want to enable optimizations and conveniences via syntax for the prototypal pattern, then declarations win, especially if they come with some ahead-of-time semantics, as top-level function declarations evaluated in a compile-and-go scenario do. Thanks to the order of function and then var declaration processing when entering an execution context, such a scenario supports the compiler pre-binding top-level functions.
>> I'm trying to relate this statement to the original "strongest case" comment above and I'm having a hard time. I probably something more concrete would help. 
> If class C {...} is analogous to function in that each evaluation generates a new C and binds it to that name, where ... is constructor code, then the parallel to function is clear and implementations can optimize accordingly (as some already do for top level functions).

In my current proposal 
  class Foo {new (x) {
       {this.x=x}   //imperative property creation like in a conventional constructor functions
is analogous to
  function Foo(x) {this.x=x} 
but a better expression of the same thing would be:
 class Foo {
     new (x) {
        x: x      //declarative property definition like in an object initialiser

You really want the declarative property form to be used as much as possible but sometimes you need to throw in a little bit of imperative initialization code.

You should probably take another look at http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_class_abstraction as it cover all the variations.

> If {...} is an expression (initialiser, with extensions), then maybe the same optimizations apply at top level, but I'm not sure, and it doesn't look analogous to function any longer.

I'm not sure which specific optimizations you have in mind.  The initialiser form seems easier to shape analysis.

> That's all. Not trying to make a mountain out of this, but either class C {...} is function-y or it isn't. Half-way in between, with an initialiser body, seems less good.

I guess, what I was trying to emphasize is that class C { } in my proposal really does create a constructor function and a prototype object just like a ES1 function declaration.   Foo can be used in exactly the same way whether it is defined as class Foo ... or function Foo ... (eg, new Foo; Foo.prototype; Foo.prototype.constructor===Foo; etc.).  However the body of a class needs to be more complex because it defines the properties of three+ objects: the constructor, the prototype, and all instances.  It can't be just a function body and it can't just be just an initailiser body although it might be closer to one or another or something else completely different. 

The main point of a class is to compartmentalize into a single unit  the structural definition of the constructor, prototype, and instances.  If all we wanted to define was the relationship between a constructor and a prototype, function already does that.  We are really looking for a syntax to make:

function Foo(x) {this.inst=x};
//often: Foo.prototype = Object.create(superclass);
Foo.prototype.m1 = function () {...};
Foo.prototype.m2 = function () {...};
Foo.cm1 = function() {...}

in to a single declarative construct where the constructor/prototype/instances methods and "instance variables" are easily identifiable by humans and tools.

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

More information about the es-discuss mailing list