7 ms·

The ES6 class system seems to be done to feel more like java and c# without regard for the mixin/prototype parts. I'm glad React still works with mixins. (edit

The ES6 class system seems to be done to feel more like java and c# without regard for the mixin/prototype parts. I'm glad React still works with mixins. (edit spelling and clarification)

stupidcar 12y ago
The ES6 class system is literally just syntactic sugar for prototypal inheritance.
- TazeTSchnitzel 12y ago
  No, it's syntactic sugar for one particular approach to using prototypical inheritance that resembles "traditional" OOP.
  - bloodyowl 12y ago
    no, it's just syntactic sugar
  - Touche 12y ago
    Can you explain? It's sugar for this very common pattern: function Bar() { Foo.call(this); } Bar.prototype = Object.create(Foo.prototype); Bar.prototype.constructor = Bar; Foo.prototype.thing = function() { .... What other "approach" to prototypical inheritance is there in JavaScript? The module pattern doesn't use prototypes.
    - backslash_16 12y ago
      Is there a good book or website to learn about prototypical inheritance? I've read a lot of Crockford's book and some stuff online about it, but I've never run across the pattern you use above. It would be great to know what the benefits are vs declaring function literals on an object, or declaring a function directly on Bar's prototype.
      - cstrahan 12y ago
        Mozilla's documentation does a good job explaining prototypal inheritance: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inhe...
      - jurassic 12y ago
        My "Aha!" moment came while reading this Kyle Simpson blog series http://davidwalsh.name/javascript-objects http://davidwalsh.name/javascript-objects
    - jbergens 12y ago
      This blog post and presentation discusses this in more detail. http://ericleads.com/2013/02/fluent-javascript-three-different-kinds-of-prototypal-oo/ http://ericleads.com/2013/02/fluent-javascript-three-differe...
  - kendallpark 12y ago
    I think one of the biggest irks for me personally when using ES6 is how `this` works. class Foo { constructor() { this.whatever = 4; } bar() { this.whatever = 3; } } var foo = new Foo(); blah.onSomeEvent(foo.bar); // When SomeEvent is triggered on blah, `this` will refer to blah, not foo. console.log(blah.whatever); // 3 console.log(foo.whatever); // 4 // You have to: blah.onSomeEvent(foo.bar.bind(foo)); console.log(blah.whatever); // undefined console.log(foo.whatever); // 3 Which I know is just traditional JS, but it's a little unexpected because that's not how most OO languages operate.
- grandalf 12y ago
  If one is not confused by prototypical inheritance, is there any reason to use the ES6 class system?
  - bloodyowl 12y ago
    it reduces the necessary LoC and forces you to only define methods in the [[Proto]] land. ES7 will let you define properties in it, but it will effectively be as if you defined them in the constructor.
    - Touche 12y ago
      Yes, it prevents the very common mistake of putting an object on the prototype.
  - acdlite 12y ago
    - More declarative. - Harder to screw up. Even if you know what you're doing, prototypical inheritance involves several steps which can get repetitive. - Interoperable with non-es6 "classes". It's not like you're losing anything.
    - jsnoble 12y ago
      Actually it might be easier to screw up. People will think these are real traditional "OO" classes but they are not. Its all prototypal, and you will be in a world of hurt creating bug and performance hits if you treat them as if they are the same. Also, functions inside a ES6 class are hijacked. You cannot bind those functions to work on another context which is a core javascript technique, it will break. Thus in the end, any person familiar with javascript will have to learn even more caveats which will create more confusion. You wouldnt want to use ES6 classes on anything super complex.
- aikah 12y ago
  no, it introduces a "super" semantic with late binding ,something you can't do in ES5. So it isn't just syntactic sugar. Furthermore it may evolve in later versions of ES to something even more complicated with access modifiers and things like that.
  - __david__ 12y ago
    Isn't it just (untested, probably full of errors): function super(obj, method) { for (var p = obj.prototype; p; p = p.prototype) if (p[method]) return p[method]; throw method+" not found"; } then use: subclass.prototype.overridden = function(x,y) { super(this, 'some_overriden_method').call(this, x, y); // ... } If so, that means it's just sugar. If not, what does it do differently?
- s1300045 12y ago
  Which is ultimately what separates a good language from a bad language. A good language should have ONE best way to do things. With the prototypical inheritance, there are impossible numbers of way to declare/define and inherit a class in JavaScript. That is just a trap for bugs and defects. How could you effectively understand what the code does when you can't read it in one glance? Especially code that is not yours. ES6's class system is infinitely better.

The ES6 class system seems to be done to feel more like java and c# without regard for the mixin/prototype parts. I'm glad React still works with mixins. (edit spelling and clarification)

stupidcar 12y ago

The ES6 class system is literally just syntactic sugar for prototypal inheritance.

TazeTSchnitzel 12y ago
No, it's syntactic sugar for one particular approach to using prototypical inheritance that resembles "traditional" OOP.
- bloodyowl 12y ago
  no, it's just syntactic sugar
- Touche 12y ago
  Can you explain? It's sugar for this very common pattern: function Bar() { Foo.call(this); } Bar.prototype = Object.create(Foo.prototype); Bar.prototype.constructor = Bar; Foo.prototype.thing = function() { .... What other "approach" to prototypical inheritance is there in JavaScript? The module pattern doesn't use prototypes.
  - backslash_16 12y ago
    Is there a good book or website to learn about prototypical inheritance? I've read a lot of Crockford's book and some stuff online about it, but I've never run across the pattern you use above. It would be great to know what the benefits are vs declaring function literals on an object, or declaring a function directly on Bar's prototype.
    - cstrahan 12y ago
      Mozilla's documentation does a good job explaining prototypal inheritance: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inhe...
    - jurassic 12y ago
      My "Aha!" moment came while reading this Kyle Simpson blog series http://davidwalsh.name/javascript-objects http://davidwalsh.name/javascript-objects
  - jbergens 12y ago
    This blog post and presentation discusses this in more detail. http://ericleads.com/2013/02/fluent-javascript-three-different-kinds-of-prototypal-oo/ http://ericleads.com/2013/02/fluent-javascript-three-differe...
- kendallpark 12y ago
  I think one of the biggest irks for me personally when using ES6 is how `this` works. class Foo { constructor() { this.whatever = 4; } bar() { this.whatever = 3; } } var foo = new Foo(); blah.onSomeEvent(foo.bar); // When SomeEvent is triggered on blah, `this` will refer to blah, not foo. console.log(blah.whatever); // 3 console.log(foo.whatever); // 4 // You have to: blah.onSomeEvent(foo.bar.bind(foo)); console.log(blah.whatever); // undefined console.log(foo.whatever); // 3 Which I know is just traditional JS, but it's a little unexpected because that's not how most OO languages operate.
grandalf 12y ago
If one is not confused by prototypical inheritance, is there any reason to use the ES6 class system?
- bloodyowl 12y ago
  it reduces the necessary LoC and forces you to only define methods in the [[Proto]] land. ES7 will let you define properties in it, but it will effectively be as if you defined them in the constructor.
  - Touche 12y ago
    Yes, it prevents the very common mistake of putting an object on the prototype.
- acdlite 12y ago
  - More declarative. - Harder to screw up. Even if you know what you're doing, prototypical inheritance involves several steps which can get repetitive. - Interoperable with non-es6 "classes". It's not like you're losing anything.
  - jsnoble 12y ago
    Actually it might be easier to screw up. People will think these are real traditional "OO" classes but they are not. Its all prototypal, and you will be in a world of hurt creating bug and performance hits if you treat them as if they are the same. Also, functions inside a ES6 class are hijacked. You cannot bind those functions to work on another context which is a core javascript technique, it will break. Thus in the end, any person familiar with javascript will have to learn even more caveats which will create more confusion. You wouldnt want to use ES6 classes on anything super complex.
aikah 12y ago
no, it introduces a "super" semantic with late binding ,something you can't do in ES5. So it isn't just syntactic sugar. Furthermore it may evolve in later versions of ES to something even more complicated with access modifiers and things like that.
- __david__ 12y ago
  Isn't it just (untested, probably full of errors): function super(obj, method) { for (var p = obj.prototype; p; p = p.prototype) if (p[method]) return p[method]; throw method+" not found"; } then use: subclass.prototype.overridden = function(x,y) { super(this, 'some_overriden_method').call(this, x, y); // ... } If so, that means it's just sugar. If not, what does it do differently?
s1300045 12y ago
Which is ultimately what separates a good language from a bad language. A good language should have ONE best way to do things. With the prototypical inheritance, there are impossible numbers of way to declare/define and inherit a class in JavaScript. That is just a trap for bugs and defects. How could you effectively understand what the code does when you can't read it in one glance? Especially code that is not yours. ES6's class system is infinitely better.