Sep 27 meeting notes
waldemar at google.com
Fri Sep 30 14:17:04 PDT 2011
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.
More information about the es-discuss