Sep 27 meeting notes

[Brendan Eich]

On Sep 30, 2011, at 2:38 AM, Waldemar Horwat wrote:

> On 09/29/2011 05:08 PM, Bob Nystrom wrote:
>> 
>> 
>> On Thu, Sep 29, 2011 at 4:22 PM, Erik Arvidsson <erik.arvidsson at gmail.com <mailto:erik.arvidsson at gmail.com>> wrote:
>> 
>>    However, it seems like all the issues we have seen are due to us
>>    trying to solve issues that already exist today with prototype based
>>    "classes". These involve (but are not limited to):
>> 
>>    1. Don't let uninitialized objects escape
>>    2. Ensure the shape of the instance
>>    3. Initialization of instance properties
>>    4. Allow const classes
>>    5. Allow const properties
>>    6. Play well with future type guards
>> 
>> 
>> I was tinkering with some syntax ideas last night and had the same revelation. It feels like we've over-constrained ourselves.
> 
> I get that feeling as well.
> 
>> In particular, if you're willing to discard 2 and 6 (basically not worry about a declarative form for instance properties) I think it gets a lot easier.
> 
> Yes, it's easier, but you'd also lose any convenient way of doing 5.

Is 5 by itself important? Almost all JS uses today (those that don't exploit ES5 Object.defineProperty) use writable instance variables, whether by the closure pattern or the prototypal pattern.

Classes as sugar, if it can be done, means avoiding new kernel semantics until we know how to add them, or there are new long-hands to sugar.


>  2, 4, and 5 are the most important new features, and there isn't enough value in classes to add them without those.

This seems like a fundamental conflict with "classes as sugar" unless we take the Object.defineProperty semantics as the "salty" long-hand to sugar.


>  If you find it difficult to come up with a proposal that can accommodate them, it's a sign that you're about to design yourself into a corner.

Or you need to defer 2 and 5 without future hostility. Why is leaving 'const' or anything equivalent for instance variables out, and letting the constructor assign or define all |this| properties, designing anything into a corner?

I agree we should support 4, Mark does too. But it is purely a desugaring step as I've shown.


> Constraint 1 is the one above that I'd relax.  All simple ways I've seen to to do it are variants of zero-inheritance.

No one wants zero-inheritance, and it doesn't help solve 2 and 5 anyway. Even a zero-inheritance class in the current proposal on the wiki can have "public const k = x*y" in its constructor and have uses of k before the initializer has been evaluated, or exits from the constructor leaving it unevaluated.

/be