Sep 27 meeting notes

[Bob Nystrom]

On Fri, Sep 30, 2011 at 3:38 PM, David Herman <dherman at mozilla.com> wrote:

> 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.
>

Agreed completely.

With the class proposal we're mostly focused on the contentious parts, but I
think it's easy to forget how much nicer just having extends Foo and
super.foo() would be over what we have today.

I also personally really dig seeing an entire kind-of-thing defined in one
nice neat curly block instead of a constructor function and a bunch of
dangling imperative modifications after that.

- bob


> 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
>
>
>
> _______________________________________________
> 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/a111a9e4/attachment.html>