Sep 27 meeting notes

[David Herman]

I pretty much agree with Axel's goals listed here. But I don't think Mark or Waldemar do. As Erik says, this seems to be the biggest sticking point.

As for IDE's, I'm with Allen: we don't need to bend over backwards. The worst offender I've seen was the design that involved uninitialized property declarations in the class body, only to assign the properties in the constructor body anyway. This just seems like extra make-work for no particular gain; I'd rather let the IDE do the work of inferring the properties from the body. (If you want to document type information about the properties in comments or something, put them with the class declaration or the constructor declaration.)

But when Waldemar said:

>> 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. The super patterns are really painful and easy to get wrong in existing JS, and the benefits of combining a prototype declaration and constructor declaration in a single form shouldn't be dismissed. It's noticeably more readable and it codifies and standardizes a common pattern.

Dave

On Sep 30, 2011, at 2:49 PM, Axel Rauschmayer wrote:

>> From: Waldemar Horwat <waldemar at google.com>
>> Subject: Re: Sep 27 meeting notes
>> Date: September 30, 2011 23:17:04 GMT+02:00
>> To: Brendan Eich <brendan at mozilla.com>
>> Cc: es-discuss <es-discuss at mozilla.org>, Erik Arvidsson <erik.arvidsson at gmail.com>
>> 
>> Without 2, 4, and 5, object initializers are close enough to make having an extra class facility not carry its weight.
> 
> 
> Can you show code that backs up that assertion? (I’m curious, not dismissive.)
> 
> Wasn’t it David Herman a while ago who listed a minimal feature list? For me it would be:
> 
> 1. Super property references (mainly methods)
> 2. Super constructor references
> 3. Subclassing (mainly wiring the prototypes)
> 4. Defining a class as compactly as possible (with subclassing, it is painful that one has to assemble so many pieces).
> 5. Having a standard construct that fosters IDE support. Currently there are too many inheritance APIs out there, making IDE support nearly impossible.
> 6. A platform on which to build future extensions (traits!).
> 
> Allen’s object literal extensions give us #1 and #2. His prototype operator gives us #3. #4 can be done via Allen’s pattern or by introducing the methods
> - Function.prototype.withPrototypeProperties(props)
> - Function.prototype.withClassProperties(props)
> 
> I’m not sure about #5 (I’d consider class literals a plus here). #6 can be postponed if we can get 1-5 by other means, but there will be a price to pay if two competing ways of defining classes have to be used in ES.next.next.
> 
> -- 
> Dr. Axel Rauschmayer
> 
> axel at rauschma.de
> twitter.com/rauschma
> 
> home: rauschma.de
> blog: 2ality.com
> 
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110930/bd35c521/attachment.html>