"I'm not very interested in the classical vs prototypal battle. Both are
barely different mechanisms of specialization."
I couldn't disagree with that more strongly. Just because you can mimic
class easily with prototypes doesn't make them "barely different". If
you're not interested in that conversation, you can safely ignore
everything else I have to say, because you've effectively blown it off. Stick
your head in the sand if you like. The problem doesn't go away.
"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."
Basically, my argument is that the whole paradigm of a class with a single
ancestor, and any mention of that ancestor in the implementation of the
child (referring to the parent in the constructor, for instance), is
fundamentally flawed and problematic. `extends` harms code maintainability
by virtue of creating the brittle hierarchy / gorilla-banana problem I've
already described.
The problem isn't how it's done in JavaScript or ES6. The problem is that
it's done at all.
Class gets people thinking in a fundamentally broken paradigm for good OO
design.
I saw a recent example of one of the problems with single-ancestor
inheritance in a talk. I wish I could remember which one. The illustrations
were great:
Animal
- Walking
- Monkey
- Human
- Flying
- Bird
- Bee
- Swimming
- Fish
- Whale
Now we need alligator and duck.
I understand that JavaScript doesn't restrict you from doing things like
mixins as well... but when you're 14 months into a project, and THEN you
have to add the alligator, suddenly you're mixing paradigms in ways that
diverge significantly from the style of the rest of the code base. At this
point, the code is already arthritic and brittle. Fitting these things in
at this point is a lot less trivial.
If you're relying on things like super in the rest of the code, how does
the new stuff properly invoke the constructors of multiple ancestors which
are designed to be single ancestors?
I can tell you how I've seen these situations handled in the real world,
virtually everywhere the problem has cropped up (pretty much everywhere
that class was relied on heavily). Massive refactors. Code rewrites. Lots
of wasted time.
Class sugar might save developers a few keystrokes today, but it will come
back to bite them hard later. Lots of people are paying for Backbone's
.extend().
If it added value, that would be one thing. But it doesn't actually do
anything that couldn't have been done just by replacing it with a
constructor that produced objects that could be passed into those
constructors to produce new objects. I have seen the problems in code at
Adobe, at Tout, and at BandPage (my last three jobs, that all used
Backbone).
The problem isn't with Backbone's particular implementation. I had the same
problems in C++, Java, and with John Resig's Simple Inheritance in
JavaScript.
The problem isn't with the ES6 implementation. It's the whole paradigm.
- Eric
On Fri, Jun 28, 2013 at 2:27 PM, David Bruant <bruan...@gmail.com> wrote:
> 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
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
