Sep 27 meeting notes

[Waldemar Horwat]

On 09/30/2011 01:20 AM, Brendan Eich wrote:
> 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.

Without 2, 4, and 5, object initializers are close enough to make having an extra class facility not carry its weight.

     Waldemar