On May 19, 2011, at 11:02 AM, Bob Nystrom wrote:
> On Thu, May 19, 2011 at 10:50 AM, Brendan Eich <bren...@mozilla.com> wrote:
> Don't take this the wrong way ;-), but how many of those initializations were
> immediately overwritten by the constructor, unconditionally or even
> conditionally?
>
> Heh, zero, actually. We're pretty scrupulous here. The 34 examples fell
> roughly into these buckets:
>
> 1. State that just always started a certain way: this.checked = false;
> 2. Collections that are mutated, but never assigned: this.items = [];
> 3. Objects used to compose a larger one: this.myButton = new Button("label");
>
> If it was ever assigned to in the ctor using state passed in, or in a control
> flow path that was dependent on ctor arguments (or this), I didn't count it
> in the 34.
Thanks for measuring, helpful beyond our qualitative arguments.
Here's another question: how many property initializations could be done
straight from the parameter of the same name?
And here's the punchline: we are forgetting about parameter default values:
http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values
Apart from the desire to declare per-instance property names, do we really need
default values if the constructor author could write default parameter values?
class Point {
constructor(x = 0, y = 0) {
this.x = x;
this.y = y;
}
...
}
Now, Scala and CoffeeScript fans will object to repeating x and y three times.
IIRC an earlier proposal even allowed for the concise syntax
class Point {
constructor(this.x = 0, this.y = 0) {
}
...
}
The CoffeeScript syntax is even sweeter:
class Point {
constructor(@x = 0, @y = 0);
...
}
The objection here is that @ is coveted, for private names or decorators.
Perhaps we could use leading dot in formal parameter names to mean this.:
class Point {
constructor(.x = 0, .y = 0);
...
}
Comments welcome!
>> 4. It's terse:
>>
>> class Stack {
>> public items;
>> constructor() {
>> this.items = [];
>> }
>> ...
>> }
>>
>> class Stack {
>> public items = [];
>> ...
>> }
>
> You'd need a fresh [] evaluation per construction. Mark pointed out how this
> seems to change the evaluation rules for the immediate elements of the class
> body. Not fatal but another kind of inconsistency, along a different
> dimension.
>
> I agree, this part feels a little weird. The fact that we're doing anything
> per-instance in the class body is probably the strangest part of this
> proposal since the other two objects touched by the class body (the ctor
> object and the prototype) are both singletons. Even declaring per-instance
> properties there feels a little strange, but I think it's generally worth
> that inelegance. <shrug>
See if my parameter default value pitch does not provide a better alternative.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
