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
numerous.
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.
Thanks,
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
