I noted some open issues on "Classes with Trait Composition"

Brendan Eich brendan at mozilla.com
Thu May 19 11:47:39 PDT 2011


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) {
  }
 ...
}

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110519/1718c3ec/attachment.html>


More information about the es-discuss mailing list