David Bruant bruant.d at gmail.com
Fri Jun 28 14:27:34 PDT 2013

Hi Eric,

Le 28/06/2013 19:42, Eric Elliott a écrit :
> I know this has been batted around already.
Has it? :-p

> I know everybody's totally stoked about class sugar in ES6. I just 
> wanted to register my protest. I made my arguments in this talk at Fluent:
> http://ericleads.com/2013/06/classical-inheritance-is-obsolete-how-to-think-in-prototypal-oo/
Adding the class keyword into JavaScript does not mean adding all the 
constructs that Java has and all the problems that come along. Given the 
*current* ES6 class proposal, what issues do you see that would affect 
code maintainability?

> I'm already seeing nasty codebase arthritis creep into JavaScript 
> projects thanks to things like Backbone.View.extend() being 
> essentially mandatory.
Don't use Backbone?
Can you expand on an example of what you call "nasty codebase arthritis" 
using Backbone?

> Providing sugar to extend classes in JavaScript proper is like 
> officially sanctioning that nonsense.
> I'm not the only one who feels that way. Here's an excerpt from one 
> viewer's comment on my presentation:
> "I think this will only get worse with ES6 and I am rather upset about 
> it. While 'class' will be elective of course, I can only imagine more 
> and more libraries adopting the ES6 class pattern, and then we will 
> wind up facing the same set of challenges that exist in the Java world."
ES6 classes will desugar at runtime into JavaScript objects as we know 
them. How does the introduction of ES6 classes bring challenges that 
don't already exist in JS? Please be specific and provide examples.
Having two keywords in common ("class" and "extends") doesn't mean 
issues in one language will shift to the other.
Also, having a new syntax sugar doesn't take anything off of the 
language; solutions of yesterday will work tomorrow.

> In my opinion, the clamoring for class in JavaScript is because 
> JavaScript tries to hide prototypes, rather than make it easy to deal 
> with them.
Not sure where you got that from. It's been a very clear goal to make 
ES6 classes desugar into objects as we know them. This constraint causes 
some headaches (semantics of upcoming private keyword comes to mind :-) 
), but everyone I've read from on that list stands by this constraint.

> Instead of class, we should let library authors continue to experiment 
> with other inheritance patterns in JavaScript. Here's an example:
> https://github.com/dilvie/stampit
> We do need a bit more object sugar in JS, but I think we should wait 
> for some patterns to gain a foothold in the wild, and only when 
> popular patterns emerge and have time to be tested and proven to be 
> well-thought-out and a valuable addition (unlike Backbone's .extend(), 
> which is causing lots of problems in the real world), only THEN should 
> the idea be blessed by the specification.
The author experimentation can happen even if there is a class syntax in 
the language.

> Is class a good idea in JavaScript? I say, prove it. In fact, anything 
> that can have a reference implementation should be proven - not just 
> by implementing it to see if it can work, but if it can be polyfilled 
> (or something like it could be polyfilled), put it in a library and 
> see if it catches on before you add it to the spec, and everybody 
> starts to write about it in their "new JavaScript features" posts.
I'm just someone sending emails, but what you're describing (prototype 
features in libraries and spec what catches on) is how I have observed 
TC39 working.
Function.prototype.bind comes from that (jQuery, underscore). Array 
functional methods (jQuery each, SpiderMonkey). Arrow functions 
(CoffeeScript). Promises!!
I think examples of ES5/6 picking things that have proven to work are 

Polyfillability is good if possible, but shouldn't be a goal. Some 
things lack in the language semantics. Those are usually things you 
can't polyfill.

> So far, NO IMPLEMENTATION of class in JavaScript has become a de-facto 
> standard. I think we should set the bar a little higher where a new 
> feature could actually cause damage to the language ecosystem.
Lots of people have been asking for classes, lots of terrible libraries 
trying to emulate what can be done in Java have been implemented. And 
Backbone.extends now. And many others to come.
ES6 is coming up with a class syntax that will satisfy these people and 
desugars to ES5 runtime semantics. That's a good tradeoff in my opinion.

I'm not very interested in the classical vs prototypal battle. Both are 
barely different mechanisms of specialization.
At the pace we're at, the class syntax will make it into ES6. People 
want it, they will have some form of it, that's inevitable. It's in 
TypeScript and CoffeeScript; even if it wasn't in the core language, 
you'll have to deal with codebases using classes in the future.
I'm however very interested if you could take a look at the current 
proposal and tell if you can pin down how the current proposal makes 
classes harmful for code maintainability.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130628/9d2e6655/attachment.html>

More information about the es-discuss mailing list