chris.ryan.det at gmail.com
Sat Jun 29 19:22:55 PDT 2013
Do we need classes at all? In my opinion, given that the concept is
implemented in a clear manner and it is possible to be powerful enough
to be of use in favour of prototyping (and developing based on the
prototypal concept instead), then yes, it would have my support.
However, my major gripe with the current classes proposal (and in fact
with a few other proposals too, but that's a different story) is that
it's just syntactic sugar added for the sake of it - it doesn't add
any sort of functionality that cannot be implemented another way with
the current toolset, and this contraption will only add complexity and
confusion to the language.
Developers from object-oriented background will inevitably assume
because ES6 has native classes and its syntax is almost exactly the
same to what they are used to, that they will behave in a similar
manner to the classes that they are used to in Java, C#, C++, etc.
While it is obviously wrong to assume so, naturally they will apply
similar methods of doing things that they did in their old language
that used classes extensively, causing many issues when their code
doesn't behave in the same manner.
It's best understood when we apply the duck test to this concept:
Does it look like a duck?
Does it swim like a duck?
Does it quack like a duck?
If the answer to all three was yes, then developers are most likely to
assume that it indeed the "duck" that they are used to - only that the
animal is indeed not a duck at all. What is the point of misleading
developers into believing that it is what think it is, only for it to
not quite work how it describes: isn't that what a scam is? There is
a case in that developers from other programming languages will be
able to feel more "at home" with ECMAScript - but shouldn't we be
trying to get them to understand what it's really about, not
abstracting it into something that sort of looks like what they are
used to, but don't quite work like that? Regardless of where they
come from, most developers are unhappy to have to change their
thinking about how to program - I personally think that it's more
preferable to let them know upfront that it's not just another
language that's similar enough; ECMAScript is different enough in my
opinion to warrant this distinct difference in direction.
It also creates confusion as to which method shall be used to program
- having multiple methods to do the same thing is the classic root of
debate, confusion, misleading and downright incorrect information
being spread around, and authority figures being "in one camp",
generating mass followings and arguments between the two factions.
While you may argue that it's not the fault of the language that
people decide to argue about these sorts of things, history has shown
that programmers will argue over even the most trivial disputes over
two "correct/legal" methods of doings things - take a few common
programming conflicts: semicolon or no semicolon, tabs or spaces,
array literal notation or constructors.
If we don't need classes, there are no features introduced that do not
simplify programming significantly (e.g. destructuring assignment),
nor allow functionality not previously possible in ECMAScript (e.g.
modules), why should we press ahead with something that will just
further add fear, uncertainty and doubt into the minds of programmers,
will make the language yet more complicated to learn than before
(especially to people completely new to programming and the
object-oriented paradigm) and goes against quite a few other concepts
in use in ECMAScript code (i.e. functional programming)? It's
something that is just not needed for the development and growth of
the language - we have so many other things that we can branch off and
build upon: classes is just too much work for way too little gain.
> 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.
First of all, since they (the current builtins) are already there,
it's pretty difficult to remove them. The point of them (and in fact,
any form of syntactic sugar) is to make ideas more simple to express
while not losing any functionality. Whether classes do add simplicity
is debatable - however with more options, I would ought to believe
comes more complexity, especially since it is not inherently more
concise to express your ideas through the current classes proposal
versus through prototyping. The vast majority of the current "sugar"
methods provide a much simpler method of doing things than what is
possible without it (e.g. most of the Array methods), which is the
crucial difference between this proposal and the other methods that we
currently have. As a matter of fact, I'd think that some of the
proposals that have been mostly accepted are unnecessary as well, but
classes are such a significant departure that I'd ought to think that
this should be reconsidered.
On 29 June 2013 06:55, 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.
> it's done at all.
> Class gets people thinking in a fundamentally broken paradigm for good OO
> 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
> The illustrations were great:
> - Walking
> - Monkey
> - Human
> - Flying
> - Bird
> - Bee
> - Swimming
> - Fish
> - Whale
> Now we need alligator and duck.
> 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
> 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
> 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
> 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
> 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
> 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?
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss