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 <anguscroll at gmail.com> 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
axel at rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110711/3df1864e/attachment-0001.html>