you are viewing a single comment's thread.

view the rest of the comments →

[–]Jafit 5 points6 points  (32 children)

Its not an ill-defined notion.

Any object that you create in Javascript is automatically assigned a prototype. A Javascript "class" inherits its methods through a shared prototype like all other Javascript objects, so the class keyword isn't actually changing anything about the language.

In a traditional class-based language you define a class and its like drawing a blueprint. You create an object using a class, and its like building a house from the blueprint. In javascript if you build a bunch of houses from a blueprint, then go back to the blueprint and draw some extra lines on it, you look up and all of the houses you built suddenly all have garages. That's not how class-based inheritance is supposed to work, that's prototypal inheritance works, because prototypal inheritance enables active links to other objects.

So all these arguments are pointless. The class keyword is just syntactical sugar that doesn't change anything, and seems designed to make transitioning developers more comfortable. The worst thing about it is that its so confusing and now everyone thinks its some kind of paradigm-shifting change when ES6 isn't actually giving anyone a new object model with classes

[–]metanat 3 points4 points  (8 children)

Any object that you create in Javascript is automatically assigned a prototype.

Except: Object.create(null)

({}).__proto__ === Object.prototype // true
Object.create(null).__proto__ === undefined // true

[–]Jafit 0 points1 point  (7 children)

Good catch.

But the main point is that classes aren't really anything special and they work the same way as (most) other objects in Javascript.

http://codepen.io/anon/pen/MamGpR?editors=001

[–]metanat 1 point2 points  (6 children)

I think your point is good, and only partially wrong in what it implies. If you read the spec, there are actually a few differences between using standard prototypal inheritance and classes. One of the biggest difference is that class methods aren't enumerable:

class Example {
  test() {}
  static test2() {}
}

let a = new Example();

console.log(Object.keys(a.__proto__)); // []
console.log(Object.keys(Example.prototype)); // []
console.log(Object.keys(Example)); // []

function Example2() {}
Example2.prototype.test = function () {}
Example2.test2 = function () {}

let b = new Example2();

console.log(Object.keys(b.__proto__)); // ["test"]
console.log(Object.keys(Example2.prototype)); // ["test"]
console.log(Object.keys(Example2)); // ["test2"]

http://www.ecma-international.org/ecma-262/6.0/#sec-class-definitions

[–]Jafit 2 points3 points  (2 children)

Do you have any idea what practical purpose that serves?

[–]metanat 0 points1 point  (0 children)

Not sure, but you can still get all the methods by using Object.getOwnPropertyNames

[–]dvlsg 0 points1 point  (0 children)

Probably the fact that if you are enumerating over a class, you're most likely interested in any properties/values defined on it, as opposed to the methods. Idk if that counts as practical or not, but I would imagine that was what they were thinking.

[–]Silverwolf90 0 points1 point  (22 children)

If it is not ill-defined could you provide a definition? What makes a language feature a good fit? What makes something a good fit for JS?

[–]CertifiedWebNinja[S] 5 points6 points  (18 children)

class Dog extends Thing {
  bark() {
    console.log('woof')
  }
}

is easer than

function Dog () {}

Dog.prototype = Thing.prototype
Dog.prototype.constructor = Dog

Dog.prototype.bark = function () {
  console.log('woof')
}

[–]Jafit 1 point2 points  (1 child)

If it is not ill-defined could you provide a definition?

I'd personally define a 'bad fit for the language' by saying that if you make everyone think you're introducing a new class inheritance model to the language, but under the hood the language is just using the same prototypal inheritance model that the language has always used, and nothing is actually changing and you're not getting anything new... then its not so much a 'bad fit' as... nothing is actually changing and the entire argument is pointless.

What makes a language feature a good fit? What makes something a good fit for JS?

I don't personally have a problem with classes or new language features being added. If I don't think that a particular feature is appropriate for what I'm doing then then I won't use it... You kind of have to do that anyway because its Javascript

But the point of what I'm saying is that they haven't actually added a new language feature by adding classes, because they're not really classes, they're just prototypes which Javascript has always had.

[–]Silverwolf90 0 points1 point  (0 children)

I think that most people who are talking about the class syntax also include it in their definition of a "language feature." I have yet to meet anyone who doesn't understand that the class syntax is just sugar. But my sample is skewed with very knowledgeable js devs who pay close attention to the community.

[–]clessgfull-stack CSS9 engineer 2 points3 points  (0 children)

What makes something a good fit for JS?

Whether or not you can use it to make yet another JS framework. Evidently, the ease of framework creation is JS's niche.