On Tue, Oct 4, 2011 at 3:44 AM, Brendan Eich <[email protected]> wrote:
> 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).
That's why I was trying to make it less error prone and verbose.
>
> 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.
I was assuming <| was evaluated first because that's how I read
Allen's pattern working as well. I'm wondering how Allen's even works
now. My thought was that if func <| obj => func, then .{ would go on
the resulting function.
>
> };
>
> 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.
I'm puzzling at Allen's pattern then, because I don't see how it would
work either. If, as you're saying, the .{ has higher precedence, then
it seems to me the entire RHS would be evaluated first complete with
adjusted prototype and class members, and then handed to the <|
operator. I didn't think that was supposed to work, because the RHS
was supposed to be a literal, but the .{ are modifying it first, which
doesn't seem right.
Also, I guess I'm not entirely sure how this would work in terms of
making the prototypes/constructors all working. From what you're
saying, Allen's pattern basically does this:
const Foo = ...//setup base class with constructor and methods
const Bar = ...//setup child class with constructor and methods
//now do __proto__ magic
Bar.__proto__ = Foo;
new Bar();//Does this really do all the wiring I need?
Having tried that, it doesn't seem to do much of anything, so I guess
I assumed there was a little more work going on under the hood using
<| on functions. Or is it that it only works because of the call to
super?
Anyway, I don't want to waste your time with my confusion, I'll dig
into the docs a little more to see if I missed something, and I really
do hope you come to some agreement on something for classes. Until
there is some agreed on form, I suspect we will deal with many
incompatible libraries for a while.
Cheers,
Russ
> /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
