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