Sep 27 meeting notes

[Oliver Hunt]

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.

--Oliver

> 
>    Waldemar
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss