Hacker News Reader

Comment by MatthewPhillips | Hacker News Reader

I'm against the class keyword for a couple of reasons:

1) Prototypical inheritance is different from classical inheritance. If we add the class keyword with either have to make it work like most classical languages work (Python, Java, C#, Ruby) or we confuse new JS developers with keywords that look familiar but work differently.

2) The argument is that "you don't have to use it", which is fine, but in reality we know that browser vendors will optimize the hell out of the class keyword and we'll be forced to use it for that reason alone.

View on HN

#1 is just FUD. JavaScript is JavaScript. Class in JS is a shorthand for function and functions prototypically delegate. That you're not writing in Java/Python/C#/Ruby should be pretty obvious.

#2 doesn't bear much relationship to reality. There will be near zero correlation between "class" and performance. What can (and today, does) change the performance of objects is having their shape change markedly after construction. V8, for instance, already includes heuristics to know when a class is "done" being constructed, allowing it to apply most of the typed-language tricks in the bag for objects which are entirely unfrozen. In current code, it's actually a de-optimizer to call Object.freeze() and there's no reason to think you'll get anything faster for using "class" than by writing code which doesn't change its shape very much.

You will, however, finally be able to read and share code more easily.

> That you're not writing in Java/Python/C#/Ruby should be pretty obvious.

I don't think it's obvious at all that the keyword "class" is going to be fundamentally different from whatever OO language you are coming from. Isn't this the single biggest reason why many developers have difficulty learning JavaScript?

> There will be near zero correlation between "class" and performance.

There already is performance differences between constructor functions and Object.create (in terms of initialization, that is).

Object.create() creates no closure. You've already paid for in the context in which you're .create()-ing. In any case, performance optimization is what happens when something becomes common enough to work its way into benchmarks. And calling out a delta now that's probably not your bottleneck seems...um...less than useful.

1) Classical inheritance is a restricted form of Prototypal inheritance. They can coexist. The vast majority of the world uses Classical inheritance, and there are folks (like jashkenas) who make the case that all uses of the inheritance pattern are classical (See: http://news.ycombinator.com/item?id=2594521 ).

2) Isn't this entirely naive speculation of a technical topic? If classical inheritance can be optimized to be faster than prototypal... isn't that a good thing? Do you really think that Classical vs Prototypal inheritance is a zero-sum game?

I'll defer to language designers on whether classical is inherently faster or not. I don't know that the question has been answered yet or not. What will be optimized is a matter of priority, however, and likely classes will be given a high priority on optimization (as they should).

> 1) Prototypical inheritance is different from classical inheritance.

This may be true, but JavaScript's flavor of prototypal inheritance is much closer to classical than it is to pure Self-style prototype delegation.

In Self, you make new instances by taking an existing object and cloning it. That creates a new object that delegates directly to the one you clone from.

In a class-based language, you make new instances by invoking a constructor, which is often a method on some other object that represents the class. That creates a new instance which shares a set of methods that all other objects created from that constructor share.

Which of those sounds more like JS? JS by virtue of having constructors and `prototype` already is 90% of the way to being class-based. It just lacks the syntax to make that pleasant to work with.

In JS you share the prototype. It's dishonest to say you share the methods. Of course in most instances you only want to share the methods as sharing objects and arrays isn't often useful, but that's the way JS works.

In a classical language the methods are shared and the non-function properties are copied. I would qualify this as a more than 10% difference.

Reply on news.ycombinator.com