5 ms·

Nobody will ever give any credence to a statement like that if you do not list your reasons for why you think that.

frik 11y ago
Well, he is right, JavaScript is a Prototype based language which is technically more powerful than a class based one: https://en.wikipedia.org/wiki/Prototype-based_programming https://en.wikipedia.org/wiki/Prototype-based_programming
- reverius42 11y ago
  And it still is! So what's everyone complaining about? Language (keyword/syntax) bloat without adding new functionality?
- voyou 11y ago
  Is JavaScript really a prototype-based language? In prototype-based programming, you create an object which has shared functionality (the prototype), and then create new objects by cloning that object. That's not how you implement shared functionality in JavaScript; in JavaScript, you implement shared functionality by delegating to another object. In other words, JavaScript objects work like Python, or Ruby, or Smalltalk (yes, unlike these languages JavaScript, until ES6, makes no language-level distinction between an object which is also a class, and an object which isn't a class, but that's just a matter of syntactic sugar).
  - sago 11y ago
    The 'cloning' is abstract: it doesn't refer to an actual duplication. Typically code is delegated for performance, and data is copied or constructed. JS is prototypical. You identify the key point: there is no distinction between classes and instances. Classes are first-class objects, that can inherit themselves, and so on, and so on. Some languages (like Python) find they need these extra levels and introduce 'meta-class'es, this is irrelevant in JS. Also the last bit is why 'class' is a bad move in ES6. ES6 still makes no distinction between a class and a non-class. It still does not provide classes in the Classical inheritance mode. It is just syntactic sugar for deriving an object with prototypal inheritance. I can inherit a class from an instance, or classes from classes. All it does is bless the approach of using prototypes in ways that are recognizable from non-prototypal languages. The fact that most people will (incorrectly but understandably) assume the JS now has classes is why this is ill advised.
    - voyou 11y ago
      "The 'cloning' is abstract: it doesn't refer to an actual duplication." But it's not just abstract, it has real implications, because JavaScript objects share implementation of the delegated methods; that is, they behave just like objects in class-based languages. Classes in Python, Smalltalk, etc, are also instances; it's just that these language has facilities to produce particular sorts of instances which are well-suited for being delegated to (and take some measures to enforce the use of these facilities), whereas traditionally in JavaScript conventions are used to distinguish those object which are delegated to, and those objects which are not. However, the distinction between objects which are delegated to (i.e., classes) and object which are not exists just as much in JavaScript as it does in with classical inheritance.
      - sago 11y ago
        Of course all reuse is somewhat similar, but dividing things into separate categories (class, instance, metaclass) and enforcing rules on how they relate isn't a 'just', that's what class based inheritance is. The issue of abstraction is that, you don't implement prototypal inheritance with copying. No language does. That's why delegation is such a core part of any prototypal inheritance. There are different points and ways that happen. But all inheritance is delegation, in practice. Can you give an example of when a piece of code (i.e. not data) would be different if it were delegated vs copied?
    - deathanatos 11y ago
      > You identify the key point: there is no distinction between classes and instances. Classes are first-class objects, that can inherit themselves, and so on, and so on. Classes are first class objects in Python as well, and have their own inheritance hierarchy. (And so on, and so on.) > Some languages (like Python) find they need these extra levels and introduce 'meta-class'es, this is irrelevant in JS. JavaScript lacks metaclasses because it lacks the concept entirely… no? (Though perhaps you can take your FooClass and run it through a function, permuting it as desired, but then, you would still need to do that at every base-class's definition site.) JavaScript programmers do opine often (in my opinion) that Javascript is "prototype -based", and not single-inheritance OOP. Yet an objects behavior in JS seems exactly that of Python; if I take an object, "obj", and access obj.some_attr, I: 1. In JS: look for the attribute on the object (getOwnProperty, essentially?) In Py: look for the attribute on the object (in __dict__) 2. If not found, start In JS: follow the prototype chain In Py: follow the MRO Python just gives me exceedingly better syntax to do it with, IMHO. (Which the new additions in the article help with — I'm referring to the article's first example, in good ole JS.) This is slightly different from Java and C++, which strictly separate the whole instance-data from class methods.

frik 11y ago

Well, he is right, JavaScript is a Prototype based language which is technically more powerful than a class based one: https://en.wikipedia.org/wiki/Prototype-based_programming https://en.wikipedia.org/wiki/Prototype-based_programming

reverius42 11y ago
And it still is! So what's everyone complaining about? Language (keyword/syntax) bloat without adding new functionality?
voyou 11y ago
Is JavaScript really a prototype-based language? In prototype-based programming, you create an object which has shared functionality (the prototype), and then create new objects by cloning that object. That's not how you implement shared functionality in JavaScript; in JavaScript, you implement shared functionality by delegating to another object. In other words, JavaScript objects work like Python, or Ruby, or Smalltalk (yes, unlike these languages JavaScript, until ES6, makes no language-level distinction between an object which is also a class, and an object which isn't a class, but that's just a matter of syntactic sugar).
- sago 11y ago
  The 'cloning' is abstract: it doesn't refer to an actual duplication. Typically code is delegated for performance, and data is copied or constructed. JS is prototypical. You identify the key point: there is no distinction between classes and instances. Classes are first-class objects, that can inherit themselves, and so on, and so on. Some languages (like Python) find they need these extra levels and introduce 'meta-class'es, this is irrelevant in JS. Also the last bit is why 'class' is a bad move in ES6. ES6 still makes no distinction between a class and a non-class. It still does not provide classes in the Classical inheritance mode. It is just syntactic sugar for deriving an object with prototypal inheritance. I can inherit a class from an instance, or classes from classes. All it does is bless the approach of using prototypes in ways that are recognizable from non-prototypal languages. The fact that most people will (incorrectly but understandably) assume the JS now has classes is why this is ill advised.
  - voyou 11y ago
    "The 'cloning' is abstract: it doesn't refer to an actual duplication." But it's not just abstract, it has real implications, because JavaScript objects share implementation of the delegated methods; that is, they behave just like objects in class-based languages. Classes in Python, Smalltalk, etc, are also instances; it's just that these language has facilities to produce particular sorts of instances which are well-suited for being delegated to (and take some measures to enforce the use of these facilities), whereas traditionally in JavaScript conventions are used to distinguish those object which are delegated to, and those objects which are not. However, the distinction between objects which are delegated to (i.e., classes) and object which are not exists just as much in JavaScript as it does in with classical inheritance.
    - sago 11y ago
      Of course all reuse is somewhat similar, but dividing things into separate categories (class, instance, metaclass) and enforcing rules on how they relate isn't a 'just', that's what class based inheritance is. The issue of abstraction is that, you don't implement prototypal inheritance with copying. No language does. That's why delegation is such a core part of any prototypal inheritance. There are different points and ways that happen. But all inheritance is delegation, in practice. Can you give an example of when a piece of code (i.e. not data) would be different if it were delegated vs copied?
  - deathanatos 11y ago
    > You identify the key point: there is no distinction between classes and instances. Classes are first-class objects, that can inherit themselves, and so on, and so on. Classes are first class objects in Python as well, and have their own inheritance hierarchy. (And so on, and so on.) > Some languages (like Python) find they need these extra levels and introduce 'meta-class'es, this is irrelevant in JS. JavaScript lacks metaclasses because it lacks the concept entirely… no? (Though perhaps you can take your FooClass and run it through a function, permuting it as desired, but then, you would still need to do that at every base-class's definition site.) JavaScript programmers do opine often (in my opinion) that Javascript is "prototype -based", and not single-inheritance OOP. Yet an objects behavior in JS seems exactly that of Python; if I take an object, "obj", and access obj.some_attr, I: 1. In JS: look for the attribute on the object (getOwnProperty, essentially?) In Py: look for the attribute on the object (in __dict__) 2. If not found, start In JS: follow the prototype chain In Py: follow the MRO Python just gives me exceedingly better syntax to do it with, IMHO. (Which the new additions in the article help with — I'm referring to the article's first example, in good ole JS.) This is slightly different from Java and C++, which strictly separate the whole instance-data from class methods.