I noted some open issues on "Classes with Trait Composition"
Mark S. Miller
erights at google.com
Thu May 19 11:55:20 PDT 2011
On Thu, May 19, 2011 at 11:47 AM, Brendan Eich <brendan at mozilla.com> wrote:
> On May 19, 2011, at 11:02 AM, Bob Nystrom wrote:
>
> On Thu, May 19, 2011 at 10:50 AM, Brendan Eich <brendan at 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) {
> }
> ...
> }
>
I like Bob's "this.x" form best, especially when combined with your
observation about default values.
The reason I prefer "this.x" rather than the terser ".x" or "@x" (even
assuming away conflicts with other uses if "@"), is that I can imagine many
programmers with ES < 6 experience, on seeing a "this.x" parameter for the
first time, to be able to guess what it means.
>
> 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
>
>
--
Cheers,
--MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110519/eb55f43f/attachment-0001.html>
More information about the es-discuss
mailing list