Eric Elliott eric at ericleads.com
Fri Jun 28 17:11:41 PDT 2013


"The rest of JavaScript remains. ES6 classes are just a sugar on top of the
ES5 runtime concepts (objects with [[Prototype]], [[Get]], [[Set]], etc.)."

When class is blessed by the spec, many people will interpret it as the
default way that objects are created and inheritance is done in JavaScript.

I see that as a sad outcome for the JavaScript community. Perhaps
temporarily convenient for people from a classical background --
temporarily, but in the long run, they are not served by it.

My question to you is this:

Does class bring value to JavaScript that is currently missing?


"People already think in a broken way when it comes to software. Software
is hard. Lots of people model data inside strings. I believe this is a much
bigger problem than classes. What's the solution for stringly typed code?"

What you want for a good UX (yes, programming languages have UX) is a pit
of success -- where people do the right thing by default. A `class` keyword
gives people a pit of dispair... where it's very easy to fall into doing
the wrong thing by default. Instead of class sugar, we need sugar around
less problematic forms of code reuse.

http://www.codinghorror.com/blog/2007/08/falling-into-the-pit-of-success.html

There's good reason that class hierarchy problems have always been so
common in C++ and Java, but were almost non-existent in JavaScript until
very recently -- and it's not just because people are only just now using
JavaScript to build large applications. Some of us have been doing that
since the 90's.

JavaScript's prototypal inheritance is a pit of success. Class is a pit of
dispair.

"Classes and the single-ancestor pattern are limited in the sort of objects
they can model. Animals are such an example.
But you can model other simpler things that don't have properties that
cross over. Classes can work for these cases."

Yes, classes are limited. Unfortunately, most developers don't see the
limitations coming, and that's the crux of the problem. Counting on them to
foresee problems coming when requirements are constantly changing is a
losing strategy.

Can you give me examples of where `class` adds enough value to make up for
all its shortcomings, or is it really just a bit of sugar to help
developers avoid typing a little more?

"By that argument, we can remove maybe 70% of the JS built-ins."

Except that most built-ins in JavaScript add significant value *without*
adding significant danger that can cost developers months in refactors and
rewrites.

"Among expert-enough people, using classes may become the sign of simple
models (when there is no need for specialization) or simple specialization
patterns. That's a good thing. It's not big, but it's a good thing."

A very simple factory abstraction can do the same -- and it doesn't require
"expert-enough people", and it's much more flexible and capable (see
stampit, for example https://github.com/dilvie/stampit ). Again - without
the danger that comes with `class`.

"Does the ES6 super has the same issue than the Java one? I really don't
feel I have enough expertise in the matter to say yet."

Yes. `super()` is problematic because you have to remember to call it, or
remember not to call it, or even think about whether or not you should be
calling it. If there are instantiation details that need to be handled,
they should be hooked so that they happen automatically. There are several
good patterns for that. stampit() automatically adds init methods to a
callback queue and guarantees that they all run automatically. The
developer doesn't need to think about it. Init hooks can completely replace
the need for `super()`. I haven't called `super()` on anything since ...
2010?

And I code large JavaScript applications every day for a living. Feels
great to be liberated from it.

"choosing class or not class is rarely the heart of the problem when you've
mis-modeled your software."

It's a lot harder to mismodel your software when your objects are composed,
rather than relying on brittle class inheritance structures. That's the
whole reason you should favor composition over class inheritance.

Want to fix class in ES6? Call it something else, replace extends with
mixin, remove super, and allow any number of init functions to be added,
rather than relying on a single constructor.

"No, the problem is when people limit the way they think about software
through this only one paradigm. If this paradigm is here alongside others,
I don't see the problem. People have the choice."

JavaScript is confusing enough to people without adding `class`. Sometimes
giving people more choice is a bad thing:
http://www.amazon.com/The-Paradox-Choice-More-Less/dp/0060005696

- Eric


On Fri, Jun 28, 2013 at 3:55 PM, David Bruant <bruant.d at gmail.com> wrote:

>  Le 29/06/2013 00:14, Eric Elliott a écrit :
>
>  "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
>
> The rest of JavaScript remains. ES6 classes are just a sugar on top of the
> ES5 runtime concepts (objects with [[Prototype]], [[Get]], [[Set]], etc.).
> People already think in a broken way when it comes to software. Software
> is hard. Lots of people model data inside strings. I believe this is a much
> bigger problem than classes. What's the solution for stringly typed code?
>
>
>  I saw a recent example of one of the problems with single-ancestor
> inheritance in a talk. I wish I could remember which one.
>
> I believe it was this talk by Angus Croll
> https://speakerdeck.com/anguscroll/the-why-and-how-of-mixins-in-flight
>
>
>  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.
>
> Classes and the single-ancestor pattern are limited in the sort of objects
> they can model. Animals are such an example.
> But you can model other simpler things that don't have properties that
> cross over. Classes can work for these cases.
> I believe that these cases are numerous and classes can work for them.
>
> Classical inheritance is a problem when that's the only tool you have. But
> if you have a decent understanding of what you're trying to model, you can
> use classes when that fits and other more appropriate mechanisms when
> they're available. The very tool you use to model something can already be
> of help to others to understand the "shape" of what you're modeling.
>
>   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?
>
> Does the ES6 super has the same issue than the Java one? I really don't
> feel I have enough expertise in the matter to say yet.
>
>   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.
>
> Yes, when the wrong tool is used for a job, people pay it later. It also
> happens in JavaScript. In my experience, it's often more a problem of not
> understanding your model enough when first writing the code. In my
> experience again, it's hard to plan everything in advance and choosing
> class or not class is rarely the heart of the problem when you've
> mis-modeled your software.
>
>
>   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.
>
> This sort of argument leads us nowhere. By that argument, we can remove
> maybe 70% of the JS built-ins. All the Math functions and constants can go,
> all Array.prototype algorithms... Object.create isn't even necessary if you
> have functions and 'new', etc.
> Classes offer a nice sugar to cover *some* use cases, *some* modelisation
> cases. Among expert-enough people, using classes may become the sign of
> simple models (when there is no need for specialization) or simple
> specialization patterns. That's a good thing. It's not big, but it's a good
> thing.
>
>
>   I have seen the problems in code at Adobe, at Tout, and at BandPage (my
> last three jobs, that all used Backbone).
>
> I would be interested in see code samples describing your problem. I do
> believe you and I agree with you by intuition, but I would love to have a
> fully-fleshed example to study it and fully understand it to understand if
> some code maintainability issues.
>
>
>   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.
>
> No, the problem is when people limit the way they think about software
> through this only one paradigm. If this paradigm is here alongside others,
> I don't see the problem. People have the choice. Some will make mistakes,
> but how different is it from today?
>
> David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130628/b1df2706/attachment.html>


More information about the es-discuss mailing list