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<[email protected]<mailto:[email protected]>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
