Summary: prototypes as classes

Dmitry A. Soshnikov dmitry.soshnikov at
Mon Jul 11 13:37:03 PDT 2011

On 12.07.2011 0: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 
> <mailto:anguscroll at>> 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.

It turns our that making decisions though the prism of some concrete 
_implementation_, programmers make incorrect judgment about some 
_techniques_ of code reuse. Ideological code reuse "class" may have 
several implementations. In static second-class classes, it can be 
method-calls technique with static (and known) addresses. In contrast in 
first-class dynamic systems it can be message passing technique based on 
delegation (i.e. based on prototypes).

But still, _regardless implementation_, the concept of a class assumes 
just a _classified code_ reuse, no more, no less. That is, (1) creation 
of many instances with the same state, (2) ability to mark the instances 
with the classification tag.

Thus, the (2) is not even required. Once you've started to create many 
instances with the same state -- you already program with the concept of 
a class, i.e. using classified code reuse. E.g.:

var pointA= {x: 10, y: 20};
var pointB= {x: 30, y: 40};
var pointC= {x: 50, y: 60};

I already created (in mind, virtually) the concept of a point class. 
That's it.

And all the other stuff -- is just the _syntactic improvements_ of this 
concept. There no other reasons. Just very practical reason -- efficient 
code reuse. Don't wanna write this copy-pasted points -- move them to a 
function (as you always do, when a code is repeated more than two times) 
-- and you get constructors of JS. Don't like that classification is 
called not with the word "class" -- rename it to "class" and add another 
sugar. So -- just the sugar matters. And without the sugar, that's said 
-- only practical code reuse technique.

I hope this small table will help: Once 
again -- statics method-calls vs. dynamics and delegation/message 
passing -- are just the techniques. But a "class" is a concept, which 
can be implemented in any form. From this viewpoint JS had, have, and 
will have (sugared now) classes. Because a "class" is not a special 
keyword "class" in a lang, it's not the ability to create classes with 
this keyword, but class -- is _the ability to classify_. And how it's 
done -- either with "class" keyword or with the "function" keyword -- 
absolutely doesn't matter.

P.S.: regarding concept of mixins -- JS (starting form the time, when 
Object.extend was borrowed from Ruby to Prototype.js) has currently 
static mixins with copying own properties. In the same Ruby mixins are 
delegation-based, that is no more than just many prototypes mixed to an 
object -- change a mixed module, and all instances which are included 
the module will see these changes -- pure delegation.

P.S[1]: the same with Python. Once it has a sugar called "class" novices 
on comp.sci call it class-based. But in fact, Python is prototype-based 
language, i.e. delegation-based with "classes as sugar". The same as in 
CoffeeScript, the same as planned for ECMAScript. So there is nothing to 


>     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 
> ( 
> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list