I am warming up to class literals: they should help IDEs and will make future extensions easier (mixins etc.). Note that they are not mutually exclusive with prototypes as classes.
On Jul 11, 2011, at 22:18 , Bob Nystrom wrote: > I agree with Brendan's replies, but just to add some more color: > > On Sat, Jul 2, 2011 at 11:46 AM, Angus Croll <[email protected]> wrote: > The concept itself is very simple - a dynamic archetype to be shared by all > my instances: my prototype changes, my instances know about it. I would not > want to hide such a smart, simple concept behind the more complex and (in > this scenario) less meaningful concept of class. > > To me, that's pretty close to a "class": a thing that describes the > properties and behavior of a set of objects. Sure, you can roll in all of the > other shenanigans that Java et. al. include (final, static, nested classes, > etc.) but the real kernel is "we have a bunch of objects that are similar and > we want to define that similarity in one place." > > JS does so through MyType.prototype and class-based languages do it in a > class definition. The class syntax proposal just gives you a nicer notation > for the former. > > a) The syntax may be fixable but the logic isn't. Inheritance hierarchies are > gnarly. > - Nine times out of ten it's a re-use technique masquerading as a > classification of types. > > Agreed, completely. Deep inheritance hierachies are almost always a guarantee > of misery. But the 1 in 10 case where OOP inheritance has been a big success > is... UI frameworks. Considering how important that use case is to > JavaScript, supporting it gracefully seems reasonable to me. > > - Mixins allow objects to borrow from an unlimited number of other objects > regardless of lineage, while still allowing for organization of functions by > type. > > I'm a huge fan of mixins/traits/multiple-inheritance > (http://journal.stuffwithstuff.com/2011/02/21/multiple-inheritance-in-javascript/). > I very often find single inheritance frustrating. > > I don't like "classic" mixins because they make it too easy for a later mixin > to stomp over the methods of an earlier one. Traits solve that nicely, and > I'd like to see them in JS at some point. If we had them, I'd use them > heavily. > > At the same time, I probably bear the most responsibility for talking Mark > into taking them out of the class proposal. My reasoning was this: > > 1. Getting *any* declarative "kind of thing" syntax into JS is fantastically > hard, as you can see. > 2. We'll need something like that to hang traits/mixins off of. > 3. Traits are complex enough that they may sink the whole proposal. > > So my take was: start with a simple class syntax that lets you declaratively > express how JS is being written *right now* with single inheritance. If we > can get that into ES6, we'll be in a much better position to try to work > traits into ES7. (And even if traits never get in, I think we'll have made a > large fraction of the world's JS simpler and easier to read.) > > It's also worth remembering that this class proposal doesn't take away any of > the flexibility JS has. Your mixin system and my weird little MI one will > still work in an ES6 that has a class syntax. It's just that if you're > following the common path of defining constructor functions and adding > functions to its .prototype, then you'll have a simpler syntax for doing so. > > We're paving a footpath here, not building a fence around it. You're always > free to wander off it into the forest. > > Earlier in this thread, Brendan said "I claim we can do little to control the > outcome in terms of adoption...the classical OOP patterning in many devs' > brains, count more than our exhortations." That's sad because I think many > ex-classical programmers (myself included) grew tired of implementation > inheritance as the dominant paradigm and gravitated to JavaScript (and also > functional languages) as a refuge from the stodgy tyranny of bloated > hierarchies. > > I too grew tired of implementation inheritance, but not classes. I still > really like class-based languages, I just like ones like Python and C# (and > JS if you're loose about "class") that augment that with first-class > functions and other ways to compose behavior. > > JavaScript is on the upward path, Java on the down. We're fostering a > generation of converts from classical OOP to something more elegant, agile > and useful. It would be a shame to throw in the towel now. > > I think you're making a false dichotomy here. "Classes" doesn't always mean > Java's "sign everything in triplicate, here comes the Carpal tunnel" level of > boilerplate. Nor does it always mean C++'s "better write a style guide before > you coworker uses some hideous dark corner of the language" level of > complexity/flexibility ("comflexibility"?). Consider Smalltalk, CLOS, Python, > Ruby, or C#. You can have classes in a beautiful language. > > - bob -- Dr. Axel Rauschmayer [email protected] twitter.com/rauschma home: rauschma.de blog: 2ality.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
