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

Bob Nystrom rnystrom at google.com
Thu May 19 11:02:05 PDT 2011


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.

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>

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


More information about the es-discuss mailing list