Classical inheritance is obsolete

David Bruant bruant.d at gmail.com
Sun Jun 30 05:34:38 PDT 2013


Le 30/06/2013 04:22, Chris Ryan a écrit :
> 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.
That's a design goal. I would oppose any class proposal that would 
require new runtime constructs. The fact that it's just sugar is a good 
occasion for people to learn how the class syntax desugars in "plain JS" 
and learn how the JS runtime works under the hood.

> 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.
Some people will misuse new features of the language. It's already the 
case with current features.
Some people also try to implement classes with awful libraries. If 
anything, the class syntax is a way to show these people how it should 
be done in the language given the very language idioms.

> 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
We are. A lot of us (regulars of es-discuss) are. On my side, I've been 
contributing heavily to MDN (because it's a wiki and CC-licenced) over 
the last few years. I've been giving professional training. I'm running 
a local JS meetup in my city. Recently, I've given 2 conferences even 
traveling on my own money to do so.
I know others here are doing a lot too. Dmitry Soshnikov has an 
excellent blog that explains the language in great details. Axel 
Rauschmayer does too. He also runs a mailing-list curating excellent 
content related to JS.
I've only been describing a small fraction of what people do to educate 
others.
Yes, we would all love to have everyone understanding the language. 
We're working on it. If you want to write content explaining how 
different object modelisation problems are solved in JS, your content is 
most welcome on MDN or WebPlatform.org or your own blog at your preference.
If you have the expertise of the subtleties of object models in 
different languages, please write guides. Write an "JavaScript object 
model for Java-ers", "JavaScript object model fro C++-ers", tutorial, etc.

> not abstracting it into something that sort of looks like what they are
> used to, but don't quite work like that?
I believe that what the class syntax desugars to is better that what 
most class libraries are trying to do.

> 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.
Yes and no. As it turns out, the following pattern is close enough to 
what most people expect of a class in most cases:

     function Animal(){
         this.age = 0;
         setTimeout( () => {this.age++}, 1000 )
     }

     Animal.prototype = {
         walk: function(){
             console.walk();
         }
     }

If that is so, why having newcomers search for hours to find that this 
pattern fits their need? Why not provide that with a syntax they're 
familiar with?
It doesn't prevent to learn how the language can be otherwise used. 
Maybe they'll find your "JavaScript for Java-ers" quickly. I heard that 
MDN has been doing major improvement to its SEO recently ;-)


> 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.
Maybe the (intial!) confusion is a good thing if it gets people to think 
about their own practice. If the web had excellent CC-licenced resources 
to help people make a good decision it would reduce the confusion you're 
talking about.


> 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)
Write resources to help people make the right choice and learn right. 
The language isn't learned by people reading the spec from to bottom 
then going to a text editor. People read resources on the web and learn 
from code written by others.

> and goes against quite a few other concepts
> in use in ECMAScript code (i.e. functional programming)?
JS is a rich language that allows different styles of programming. 
Nothing wrong with that.
At scale, I prefer the risk of making wrong choices to a too restrictive 
newspeak.

> 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.
Too much work for whom?
Classes are a convenient sugar for experts and somewhat reassuring to 
people coming from other OO languages. That's enough of a gain for me.
I'll keep contributing to MDN, give training and talks to compensate the 
potential confusion.

>> 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.
I'm quite aware ;-)

> 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
Just to clarify, I didn't say that classes added simplicity. I said that 
they are a good tools for simple models. And I said that it's a nice 
sugar for expert-enough people.
Whether it adds simplicity or complexity is too hard a question for me 
to have an opinion on yet.

> 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.
But it's much clearer. Today, everything is object and function 
declarations. It isn't well-defined when people are doing a class-like 
code sharing or when they're doing something else.
The class syntax makes that pattern really clear. It also makes the 
single-inheritance use case very clear unlike what people have needed to 
come up with until today:
http://nodejs.org/api/util.html#util_util_inherits_constructor_superconstructor

Classes remove the boilerplate needed for class-like code sharing and 
add a clear visual identity. Reading lots and lots of JS, I am convinced 
it'll make my life easier.

> 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.
In what way is it such a "significant departure"?
It's pretty much the officialisation of the following pattern:
     function C(){}
     C.prototype = {
         method(){}
     }
It does feel too far away from what people write and what's in the language.

Also, I hope you're aware you don't have to use the new features. And 
the "but people will use these feature" cannot work, because people have 
been writing class libraries for some time and CoffeeScript, Dart, 
TypeScript have classes too and people use them, so you'll have to deal 
with it at some point anyway.

David


More information about the es-discuss mailing list