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

[Mark S. Miller]

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>