bruant.d at gmail.com
Fri Jun 28 15:55:26 PDT 2013
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.
> that it's done at all.
> Class gets people thinking in a fundamentally broken paradigm for good
> OO design
the ES5 runtime concepts (objects with [[Prototype]], [[Get]], [[Set]],
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
> 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
> The illustrations were great:
> - Walking
> - Monkey
> - Human
> - Flying
> - Bird
> - Bee
> - Swimming
> - Fish
> - Whale
> Now we need alligator and duck.
> 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
> 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
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
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss