bruant.d at gmail.com
Fri Jun 28 14:27:34 PDT 2013
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:
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
> 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"
> 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."
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.
> 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
> 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
> 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
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
Function.prototype.bind comes from that (jQuery, underscore). Array
functional methods (jQuery each, SpiderMonkey). Arrow functions
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
> 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...
More information about the es-discuss