On Fri, Sep 30, 2011 at 3:38 PM, David Herman <dher...@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 <walde...@google.com> > *Subject: **Re: Sep 27 meeting notes* > *Date: *September 30, 2011 23:17:04 GMT+02:00 > *To: *Brendan Eich <bren...@mozilla.com> > *Cc: *es-discuss <es-discuss@mozilla.org>, Erik Arvidsson < > erik.arvids...@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 > > a...@rauschma.de > twitter.com/rauschma > > home: rauschma.de > blog: 2ality.com > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
