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

[Brendan Eich]

On May 19, 2011, at 10:44 AM, Bob Nystrom wrote:

> On Wed, May 18, 2011 at 6:29 PM, Brendan Eich <brendan at mozilla.com> wrote:
> On May 18, 2011, at 5:57 PM, Bob Nystrom wrote:
> 
>> class Point {
>>   public x = 0, y = 0;
>> }
>> 
>> let p = new Point();
>> p.x; // 0
> 
> This is pretty rare, in my experience.
> 
> I just did some spelunking through some JS code. In about a dozen classes, I found 88 per-instance properties. Of them, 34 were initialized without reference to this or a ctor parameter, so about 39% of the properties could be expressed using the above syntax.

Don't take this the wrong way ;-), but how many of those initializations were immediately overwritten by the constructor, unconditionally or even conditionally?


> C# and Java both support this and I use it heavily.
> 
> A hard case? If the constructor does set x and y from parameters, then you have double-initialization.
> 
> Well, if you are going to initialize it in the ctor, I wouldn't bother doing so outside of it too. I'm not proposing that an initializer is required, just that it's allowed. This does a few things for me:
> 
> 1. It lets me make it obvious which instance state is ctor-dependent and which isn't. This is fairly important to me because I find it makes it easier to understand a class's state.

Good point.


> 2. It's consistent with the rest of the member declarations which allow initializers:
> 
> class Foo {
>   public onInstance = 0;
>          onPrototype = 0;
>   static onCtor = 0;
> }
> 
> Seems weird to me that the first line would be an error when the other two aren't.

Ditto.


> 3. It's consistent with Java and C# which both allow this. Not that we need to mimic those languages, but it doesn't hurt to make the most of our users' expectations.

Meh :-P.


> 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.

/be

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