Summary: prototypes as classes
rnystrom at google.com
Mon Jul 11 13:18:29 PDT 2011
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
- Mixins allow objects to borrow from an unlimited number of other objects
> regardless of lineage, while still allowing for organization of functions by
I'm a huge fan of mixins/traits/multiple-inheritance (
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
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
> functional languages) as a refuge from the stodgy tyranny of bloated
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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss