Sep 27 meeting notes
oliver at apple.com
Fri Sep 30 14:36:59 PDT 2011
On Sep 30, 2011, at 2:17 PM, Waldemar Horwat wrote:
> 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.
I disagree, people like python's classes which don't have any of these guarantees. What people want from classes seems to be a syntax that provides "classical" inheritance. Yes the current features of ES5 allow you to make such a construct, but being possible vs. being pleasant are not the same thing.
The only thing i really feel that i (personally) would want is #4. Part of me wants #2 but python has shown that's not strictly necessary.
I think we can add python style (in terms of behaviour) classes with a fairly lightweight syntax, and that syntax would not constrain future additions (declarative fields, random syntax in the argument list to aid initialisation ;) )
I think in terms of #2 there are a few different approaches to consider:
* No declarative fields -> all properties are defined with this.blah =, etc
* Declarative fields but no shape guarantees -> additional properties can be added dynamically with this.blah, etc (essentially an instance of a class is extensible), declarative fields are all !configurable on the object
* Declarative fields with shape guarantees -> logically the object is sealed, with the caveat that an instance of a subclass has all the fields of both it, and its superclass.
Resolving these and the many other issues of declarative properties would take a substantial amount of time, but does not block a basic class definition syntax that mirrors what people currently have to use libraries for.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss