5 ms·

That's because many dislike prototypical inheritance. It's perfectly usable. As for misspelling field names, the same is true for variable names in both langua

That's because many dislike prototypical inheritance. It's perfectly usable. As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. Here it's more justified, as JS semantics mean that the language can't know your intent in this case: check your spelling.

jstimpfle 10y ago
In fact what's the difference between prototypical and conventional inheritances? I think python has exactly the inheritance model of JavaScript, and statically typed languages differ only in that they make the class=type, object=value distinction (so you can't dynamically change classes).
- qwertyuiop924 10y ago
  It's not. In python, classes are entities like any other object. In JS, classes literally don't exist. Yes, even in ES6. I know there's a class keyword, but it doesn't actually create a class. What the class keyword creates is a constructor function which then initializes new objects with a set of properties, and also sets a prototype, when called with the new keyword. JS objects don't have a superclass, they have a prototype. A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype. But there's nothing special about these objects. If you wrote, say: var Person = function(){}; Person.prototype = {name:"bill", addr:"foo"}; var charlie = new Person(); charlie.name = "charlie"; charlie.addr = "baz"; var NewPerson = function(){}; NewPerson.prototype = charlie; var bill = new NewPerson(); This code is totally valid. bill's prototype chain looks like this: bill -> charlie (or NewPerson.prototype) -> Person.prototype -> ... -> Object.prototype Welcome to prototypical inheritance.
  - deathanatos 10y ago
    > A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype. A type in Python is also just another object. When a method is called, or a variable is looked up on an object, Python scans the MRO (effectively the same thing as the prototype chain, except it supports multiple inheritance too) all the way up to `object`. Python's type system is very similar, if not nearly a superset (though probably not exactly), of JavaScript's. I struggle to see the real material differences in them. Consider your example, translated: class Person: name = 'bill' addr = 'foo' class Charlie(Person): name = 'charlie' addr = 'baz' class NewPerson(Charlie): pass bill = NewPerson()
    - qwertyuiop924 10y ago
      That looks the same, but conceptually (and actually, code-wise), that's not what JS is doing. Here's what's actually happening, in psudo-python: class Person({name:"bill", addr:"foo"}): #there's no syntax for object literals in Python #such a thing doesn't even make sense: so I'm improvising. pass charlie = Person() charlie.name = "charlie" charlie.addr = "baz" class NewPerson(charlie): #note charlie is an object, not a class pass bill = NewPerson() In JS, charlie isn't a class, charlie is an object: you can change all its properties and everything, just like any other object. It's not a class, because there aren't any.
      - OOPMan 10y ago
        I notice you conveniently ignored the meta-programming capabilities of Python which would allow your "nonsensical" improvisation to work just fine. Brush up on your Python skills before talking rubbish.
        qwertyuiop924 10y ago
        Classless object literals actually don't make sense in the Python model. It seems like you're the one who needs to brush up. In any case you're not actually providing any links or facts, so unless I dig through long articles on metaclasses in python, I can't verify anything you say. Please prove your point, or at least provide I link so I can verify.
        OOPMan 10y ago
        Challenge accepted :-) It should be interesting to see if I can actually abuse Python's meta-programming enough to make it work :-)
        deleted 10y ago
        [deleted]
      - deathanatos 10y ago
        > In JS, charlie isn't a class, charlie is an object: you can change all its properties and everything, just like any other object. It's not a class, because there aren't any. Right; this is actually why I like Python's way a bit better: it makes a more formal distinction between the two. In Python, Charlie is also an object, and you can change all its properties and everything, just like most¹ other objects. Most of what you try to use to distinguish JS from Python applies just as well to Python. No, it isn't exactly the same, and I think the semantically equivalent code in Python will often contain more information than the JS. E.g., in my conversion of your JS, the class is an instance of `type`, whereas — as you correctly note — it's "just" an object in JS. It's not really though; in most JS that devs will write, the object is a type, but that distinction isn't explicit in the code. It's implicit in the dev's intentions, expressed only in the general sense that the code is being used. e.g., if I saw, in JS, var Person = function(){}; Person.prototype = {name:"bill", addr:"foo"}; var charlie = new Person(); while it is true, technically, that `Person` is a function and `Person.prototype` is an object, the semantic meaning being expressed in this manner by the author of this setup is that `Person` is a type, and that charlie is an instance of that type. It's just explicit in Python. (To some degree, JS is aware of this fact too; `charlie instanceof Person` is `true`, after all.) In a single-inheritance class in Python, during attribute lookup, Python will attempt to look the attribute up on the object's __dict__; if it doesn't exist, then it looks up the parent type (by looking at __class__) and then recurses, trying to look the attribute up there, and proceeding up the "chain".² In JS, during attribute lookup, JS will attempt to look the attribute up on the object's internal list of attribute (I don't believe this is exposed like __dict__ in Python); if it doesn't exist, then it looks up the parent type (by looking at __proto__) and then recurses, trying to look the attribute up there, and proceeding up the "chain". What material difference exists here? ¹objects in Python can forbid attributes from being set, or limit the available attributes. I'm not sure to what extend JS lets you do that. e.g., `object` in Python is very restrictive about allowing additional objects. ²I'm explicitly ignoring multiple inheritance here, so I'm vastly simplifying. Python will actually use the MRO for this procedure, but in the case of simple inheritance, that's equivalent to following __class__. I'm also ignoring __slots__ for simplicity.
  - codedokode 10y ago
    This code doesn't look good to me. What is the benefit of inheriting objects from objects instead of inheriting classes? When we have distinct functions, classes and objects we can easily understand how they are supposed to be used: you can call a function, create an instance of a class, call a method of an object. With Javascript you cannot easily see whether you have a plain function or a constructor and how you should use it. And interpreter won't tell you anything if you forget to put a `new` keyword. (And by the way why do you write 'var Person = function' instead of just 'function Person'? The latter is shorter and more readable) Your code can easily cause a bug. Imagine Person's constructor looks like this: function Person() { this.friends = []; } ... var NewPerson = function() {}; NewPerson.prototype = charlie; Do you see the problem here? To fix the problem you have to rewrite the code using Object.create() and call parent constructor with Person.call(...). I have written applications in Javascript and I think that Java-style classes are the best for readable and maintainable code. All these tricks with prototypes and dynamic objects (where you can add or patch properties in objects in runtime) might look good in short samples of code but they are only the source of bugs and cause waste of time to understand what the author meant in real world applications. Your code example proves that because adding a single field to a Person's constructor requires you to find and modify all of the objects inherited from it and this task is not easy too.
    - chriswarbo 10y ago
      It sounds like you're trying to write Javascript as if it were Java. I've worked with developers who did this (e.g. http://chriswarbo.net/blog/2014-03-12-trolled.html http://chriswarbo.net/blog/2014-03-12-trolled.html ) and I would advise that you instead try to write more idiomatic Javascript, or else use some kind of Java-to-Javascript compiler. Your critique of Javascript is basically "it's not Java". I could make a similar critique of Java not being StandardML, but it would be about as meaningless: When we have distinct structures, signatures and functors we can easily understand how they are supposed to be used: you can open a structure, create an implementation of a signature, apply a functor to a structure. > (And by the way why do you write 'var Person = function' instead of just 'function Person'? The latter is shorter and more readable) Personally, I prefer "var Person = function Person(...) {...}" since it makes the code more symmetric (the second "Person" makes stack traces more informative). The "function Person(...) {...}" style makes an artificial dinstinction between functions and everything else. > All these tricks with prototypes and dynamic objects (where you can add or patch properties in objects in runtime) might look good in short samples of code but they are only the source of bugs and cause waste of time to understand what the author meant in real world applications. Javascript is a dynamic language; there is no ahead-of-time compilation. Things can only be done at runtime, including adding properties to objects. If you mean that mutating values should be avoided, then I would emphatically agree. That's certainly not a Javascript-specific issue though, and Java is just as riddled with mutability as anything else. I haven't had enough experience with prototypical inheritance to comment on it vs class-based inheritance; I've been burned enough by class-based inheritance that I tend to avoid inheritance in all forms (and OO too, these days).
codedokode 10y ago
> As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. No. This code causes an error in PHP: $name = 'John'; echo $nmea; // error class A { public $name; } $a = new A; echo $a->nmea; // error This code doesn't raise an error in JS: var a = { name: 'John'; }; doSomething(a.nmea); // no error So with JS you learn about errors later and spend more time on debugging.
- hiou 10y ago
  Actually it throws an E_NOTICE. Something a fair amount of projects require you to turn off. You know what else throws an E_NOTICE? $a = notice_there_are_no_quotes; echo $a; // $a gets assigned the string 'notice_there_are_not_quotes' This is super fun when you attempt to use a constant and misspell it. $b = MY_CONSTANTT; echo $b; // $b is now the string 'MY_CONSTANTT' instead of whatever the correct MY_CONSTANT was set to. Which is why in both PHP and JavaScript if you really cared about what you were doing, both of those would be methods that throw errors if misspelled let a = new A(); a.setName('John'); doSomething(a.getNmea()); // Error $a = new A(); $a->setName('John'); doSomething($a->getNmea()); // Also error
  - codedokode 10y ago
    > Something a fair amount of projects require you to turn off. You know what else throws an E_NOTICE? That is true only for low quality legacy code. I have always developed with all kinds of errors enabled and converted to exceptions (that means single E_NOTICE terminates the program with exception as it is done in Java). Modern frameworks like Symfony 3 or Slim use the same approach. If you write a project using Symfony you won't miss a notice. I think default PHP error handling system is wrong - there should be no warnings or notices, only exceptions. Sadly OOP was not very popular among PHP devs in the beginning.
    - arenaninja 10y ago
      IIRC PHP3 didn't even have objects PHP4 introduced objects and is the language people shit on when they say PHP doesn't have real OOP PHP5 introduced Java-like objects PHP5.3 introduced namespaces

jstimpfle 10y ago

In fact what's the difference between prototypical and conventional inheritances? I think python has exactly the inheritance model of JavaScript, and statically typed languages differ only in that they make the class=type, object=value distinction (so you can't dynamically change classes).

qwertyuiop924 10y ago
It's not. In python, classes are entities like any other object. In JS, classes literally don't exist. Yes, even in ES6. I know there's a class keyword, but it doesn't actually create a class. What the class keyword creates is a constructor function which then initializes new objects with a set of properties, and also sets a prototype, when called with the new keyword. JS objects don't have a superclass, they have a prototype. A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype. But there's nothing special about these objects. If you wrote, say: var Person = function(){}; Person.prototype = {name:"bill", addr:"foo"}; var charlie = new Person(); charlie.name = "charlie"; charlie.addr = "baz"; var NewPerson = function(){}; NewPerson.prototype = charlie; var bill = new NewPerson(); This code is totally valid. bill's prototype chain looks like this: bill -> charlie (or NewPerson.prototype) -> Person.prototype -> ... -> Object.prototype Welcome to prototypical inheritance.
- deathanatos 10y ago
  > A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype. A type in Python is also just another object. When a method is called, or a variable is looked up on an object, Python scans the MRO (effectively the same thing as the prototype chain, except it supports multiple inheritance too) all the way up to `object`. Python's type system is very similar, if not nearly a superset (though probably not exactly), of JavaScript's. I struggle to see the real material differences in them. Consider your example, translated: class Person: name = 'bill' addr = 'foo' class Charlie(Person): name = 'charlie' addr = 'baz' class NewPerson(Charlie): pass bill = NewPerson()
  - qwertyuiop924 10y ago
    That looks the same, but conceptually (and actually, code-wise), that's not what JS is doing. Here's what's actually happening, in psudo-python: class Person({name:"bill", addr:"foo"}): #there's no syntax for object literals in Python #such a thing doesn't even make sense: so I'm improvising. pass charlie = Person() charlie.name = "charlie" charlie.addr = "baz" class NewPerson(charlie): #note charlie is an object, not a class pass bill = NewPerson() In JS, charlie isn't a class, charlie is an object: you can change all its properties and everything, just like any other object. It's not a class, because there aren't any.
    - OOPMan 10y ago
      I notice you conveniently ignored the meta-programming capabilities of Python which would allow your "nonsensical" improvisation to work just fine. Brush up on your Python skills before talking rubbish.
      - qwertyuiop924 10y ago
        Classless object literals actually don't make sense in the Python model. It seems like you're the one who needs to brush up. In any case you're not actually providing any links or facts, so unless I dig through long articles on metaclasses in python, I can't verify anything you say. Please prove your point, or at least provide I link so I can verify.
        OOPMan 10y ago
        Challenge accepted :-) It should be interesting to see if I can actually abuse Python's meta-programming enough to make it work :-)
      - deleted 10y ago
        [deleted]
    - deathanatos 10y ago
      > In JS, charlie isn't a class, charlie is an object: you can change all its properties and everything, just like any other object. It's not a class, because there aren't any. Right; this is actually why I like Python's way a bit better: it makes a more formal distinction between the two. In Python, Charlie is also an object, and you can change all its properties and everything, just like most¹ other objects. Most of what you try to use to distinguish JS from Python applies just as well to Python. No, it isn't exactly the same, and I think the semantically equivalent code in Python will often contain more information than the JS. E.g., in my conversion of your JS, the class is an instance of `type`, whereas — as you correctly note — it's "just" an object in JS. It's not really though; in most JS that devs will write, the object is a type, but that distinction isn't explicit in the code. It's implicit in the dev's intentions, expressed only in the general sense that the code is being used. e.g., if I saw, in JS, var Person = function(){}; Person.prototype = {name:"bill", addr:"foo"}; var charlie = new Person(); while it is true, technically, that `Person` is a function and `Person.prototype` is an object, the semantic meaning being expressed in this manner by the author of this setup is that `Person` is a type, and that charlie is an instance of that type. It's just explicit in Python. (To some degree, JS is aware of this fact too; `charlie instanceof Person` is `true`, after all.) In a single-inheritance class in Python, during attribute lookup, Python will attempt to look the attribute up on the object's __dict__; if it doesn't exist, then it looks up the parent type (by looking at __class__) and then recurses, trying to look the attribute up there, and proceeding up the "chain".² In JS, during attribute lookup, JS will attempt to look the attribute up on the object's internal list of attribute (I don't believe this is exposed like __dict__ in Python); if it doesn't exist, then it looks up the parent type (by looking at __proto__) and then recurses, trying to look the attribute up there, and proceeding up the "chain". What material difference exists here? ¹objects in Python can forbid attributes from being set, or limit the available attributes. I'm not sure to what extend JS lets you do that. e.g., `object` in Python is very restrictive about allowing additional objects. ²I'm explicitly ignoring multiple inheritance here, so I'm vastly simplifying. Python will actually use the MRO for this procedure, but in the case of simple inheritance, that's equivalent to following __class__. I'm also ignoring __slots__ for simplicity.
- codedokode 10y ago
  This code doesn't look good to me. What is the benefit of inheriting objects from objects instead of inheriting classes? When we have distinct functions, classes and objects we can easily understand how they are supposed to be used: you can call a function, create an instance of a class, call a method of an object. With Javascript you cannot easily see whether you have a plain function or a constructor and how you should use it. And interpreter won't tell you anything if you forget to put a `new` keyword. (And by the way why do you write 'var Person = function' instead of just 'function Person'? The latter is shorter and more readable) Your code can easily cause a bug. Imagine Person's constructor looks like this: function Person() { this.friends = []; } ... var NewPerson = function() {}; NewPerson.prototype = charlie; Do you see the problem here? To fix the problem you have to rewrite the code using Object.create() and call parent constructor with Person.call(...). I have written applications in Javascript and I think that Java-style classes are the best for readable and maintainable code. All these tricks with prototypes and dynamic objects (where you can add or patch properties in objects in runtime) might look good in short samples of code but they are only the source of bugs and cause waste of time to understand what the author meant in real world applications. Your code example proves that because adding a single field to a Person's constructor requires you to find and modify all of the objects inherited from it and this task is not easy too.
  - chriswarbo 10y ago
    It sounds like you're trying to write Javascript as if it were Java. I've worked with developers who did this (e.g. http://chriswarbo.net/blog/2014-03-12-trolled.html http://chriswarbo.net/blog/2014-03-12-trolled.html ) and I would advise that you instead try to write more idiomatic Javascript, or else use some kind of Java-to-Javascript compiler. Your critique of Javascript is basically "it's not Java". I could make a similar critique of Java not being StandardML, but it would be about as meaningless: When we have distinct structures, signatures and functors we can easily understand how they are supposed to be used: you can open a structure, create an implementation of a signature, apply a functor to a structure. > (And by the way why do you write 'var Person = function' instead of just 'function Person'? The latter is shorter and more readable) Personally, I prefer "var Person = function Person(...) {...}" since it makes the code more symmetric (the second "Person" makes stack traces more informative). The "function Person(...) {...}" style makes an artificial dinstinction between functions and everything else. > All these tricks with prototypes and dynamic objects (where you can add or patch properties in objects in runtime) might look good in short samples of code but they are only the source of bugs and cause waste of time to understand what the author meant in real world applications. Javascript is a dynamic language; there is no ahead-of-time compilation. Things can only be done at runtime, including adding properties to objects. If you mean that mutating values should be avoided, then I would emphatically agree. That's certainly not a Javascript-specific issue though, and Java is just as riddled with mutability as anything else. I haven't had enough experience with prototypical inheritance to comment on it vs class-based inheritance; I've been burned enough by class-based inheritance that I tend to avoid inheritance in all forms (and OO too, these days).

codedokode 10y ago

> As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. No. This code causes an error in PHP: $name = 'John'; echo $nmea; // error class A { public $name; } $a = new A; echo $a->nmea; // error This code doesn't raise an error in JS: var a = { name: 'John'; }; doSomething(a.nmea); // no error So with JS you learn about errors later and spend more time on debugging.

hiou 10y ago
Actually it throws an E_NOTICE. Something a fair amount of projects require you to turn off. You know what else throws an E_NOTICE? $a = notice_there_are_no_quotes; echo $a; // $a gets assigned the string 'notice_there_are_not_quotes' This is super fun when you attempt to use a constant and misspell it. $b = MY_CONSTANTT; echo $b; // $b is now the string 'MY_CONSTANTT' instead of whatever the correct MY_CONSTANT was set to. Which is why in both PHP and JavaScript if you really cared about what you were doing, both of those would be methods that throw errors if misspelled let a = new A(); a.setName('John'); doSomething(a.getNmea()); // Error $a = new A(); $a->setName('John'); doSomething($a->getNmea()); // Also error
- codedokode 10y ago
  > Something a fair amount of projects require you to turn off. You know what else throws an E_NOTICE? That is true only for low quality legacy code. I have always developed with all kinds of errors enabled and converted to exceptions (that means single E_NOTICE terminates the program with exception as it is done in Java). Modern frameworks like Symfony 3 or Slim use the same approach. If you write a project using Symfony you won't miss a notice. I think default PHP error handling system is wrong - there should be no warnings or notices, only exceptions. Sadly OOP was not very popular among PHP devs in the beginning.
  - arenaninja 10y ago
    IIRC PHP3 didn't even have objects PHP4 introduced objects and is the language people shit on when they say PHP doesn't have real OOP PHP5 introduced Java-like objects PHP5.3 introduced namespaces