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.
Allen_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
