On Nov 15, 2011, at 4:08 PM, Russell Leggett wrote:
> At this point, since it seems to me easy enough to implement as a function,
> is there a reason to go all the way to an operator. I think if you include
> the ability to have a declarative style with a name, then it pushes it over
> the top from a little sugar, to a comfortable familiar syntax.
>
> class Point {...} //constructor has the correct name, Point is a declared
> variable
> //vs
> let Point = class {...}
That's where I am if we are going to add class, and dherman's proposal looks
pretty good to me:
http://wiki.ecmascript.org/doku.php?id=strawman:minimal_classes
Class body is custom, uses best-of special forms (method definitions without
comma separators, no data property on the prototype declarative form, other
declarative forms look like declarations).
If we could have radical class-as-operator that composes without mutation, I
would be overjoyed. We should keep working on it, I agree with MarkM.
The other way to go is to make
class E
(for any expression E) always desugar to a new object with a new constructor
that calls E.constructor if present:
do {
let %e = E;
let %f = function /* NAME */ (...args) {
return ('constructor' in %e) ? %e.constructor.apply(this, args) : void 0;
};
let %o = %e <| { constructor: %f };
%f.prototype = %o;
%f;
}
The /* NAME */ bit could be imputed from new syntax if we want to support
class N E
or (in this case a special form that restricts E to be an object literal):
class N {...}
There would be no comma abatement, no static or private declarations, and data
property initialisers might be in ... and problematic on the prototype if they
have mutable values.
I'm not selling this yet, just exploring the class-as-unary-operator idea and
avoiding the "maybe it's a new object, maybe's the operand" problem by always
making a new object.
/be_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
