On Oct 4, 2011, at 5:43 AM, Russell Leggett wrote:
> I don't want to be pushy, so this is the last time that I'll mention
> it, but if we can create something using the <| operator that can
> basically do what has been discussed for the simplest class literal,
I think you're barking up several wrong trees. But yes, Allen proposed <| and
.{ to help make class-like syntax lighter-weight (if more punctuated), without
having real class syntax. Unfortunately any such poor-person's "class unsyntax"
will remain error prone (easy to leave out or misorder a sub-expression) and
slightly verbose (compared to just-so class syntax).
> but without the class keyword, it would leave the door open for a
> future spec. This was was my proposal from before:
>
> const ClassName = SuperClass <| {
> constructor(/*constructor parameters */) {
> //constructor body
> super.constructor(/*arguments to super constructor */);
> this.{
> //per instance property definitions
> }
> }
> method1(){ return super.method1(); }
> method2(){}
> prop1:"Properties unlikely, but allowed"
> }.{
> //class properties
> staticMethod(){}
These go on the constructor, not the prototype. But to the left of .{ is an
object (literal), not a function.
If you are assuming .{ binds to the result of evaluating the unparenthesized <|
expression to its left, then there's a precedence problem.
> };
>
> Where SuperClass is a constructor function, so LHS: function, RHS:
> object literal == class without the keyword.
This completely breaks <| as the set-__proto__-at-birth operator.
Allen's pattern,
const px = Name.create(‘x’), py = Name.create(‘y’);
let Point = Base <| function (x, y) {
super();
this[px] = x, this[py] = y;
this.r = function() { return Math.sqrt(x*x + y*y); }
}.prototype.{
get x() { return this[px]; },
get y() { return this[py]; },
proto_r() { return Math.sqrt(this[px] * this[px] +
this[py] * this[py]); },
equals(p) { return this[px] === p[px] &&
this[py] === p[py]; }
}.constructor.{
allPoints: [] // class “static” property!
}
works without hardcoding <| for class inheritance in the way you suggest, and
without precedence shifts or implicit switch to constructor from prototype, or
prototype from constructor.
/be
> In the most common case,
> there wouldn't be any "static" methods/properties so you normally
> wouldn't even need the slightly awkward use of '.{' here.
>
> - Russ
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
