4 ms·

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, class

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
  I am trying to write a code that is readable and maintainable instead of building complex abstractions. That is where Java classes fit perfectly (unless you are a beginner who had just read a book on patterns and tries to use every one). And I am not only person who needs classes in JS: https://github.com/search?l=JavaScript&q=class&type=Repositories&utf8=%E2%9C%93 https://github.com/search?l=JavaScript&q=class&type=Reposito... I do not see any benefit in prototypes. It just makes code more complicated and buggy. I would happily use them if I knew a way to do it while keeping code simple. > When we have distinct structures, signatures and functors we can easily understand how they are supposed to be used Yet Javascript has neither of those. > If you mean that mutating values should be avoided No, I am ok with mutable values.
  - chriswarbo 10y ago
    > I am trying to write a code that is readable and maintainable instead of building complex abstractions. My point is that what's "readable and maintainable" depends on the language; especially on what facilities it provides, and to some extent community consensus (what's 'idiomatic'). Javascript's main facilities are first-class functions with lexical scope, lightweight key/value mappings (which it calls "objects") and prototypical inheritance between those objects. Java's main facilities are classes with properties and methods; whilst it's recently gained first-class functions, most Java code has been written without them, and they'll always be in competition with classes+methods (e.g. look at all of the APIs which use single-method classes, like "Comparator"). These are very different, so what's readable/maintainable will differ in each. For example, Javascript's objects are so lightweight that it's idiomatic to write them inline exactly where they're needed, like 'foo({bar: function() { ... }, ...})'. In idiomatic Java, such objects should be instances of a class, which should either be global or else implement a global interface. Since global class/interface declarations require standalone files, our declarations end up very far away from the use site; this prevents us accessing the use-site's scope and puts us under more pressure to make it descriptive, generic, reusable, etc. > Yet Javascript has neither of those. ES6 has a module system, Java has its "package" system. Trying to apply SML practices to either is a bad idea, just as trying to apply Java OO practices to JS is a bad idea, or trying to apply Lisp macro practices to C is a bad idea.

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
I am trying to write a code that is readable and maintainable instead of building complex abstractions. That is where Java classes fit perfectly (unless you are a beginner who had just read a book on patterns and tries to use every one). And I am not only person who needs classes in JS: https://github.com/search?l=JavaScript&q=class&type=Repositories&utf8=%E2%9C%93 https://github.com/search?l=JavaScript&q=class&type=Reposito... I do not see any benefit in prototypes. It just makes code more complicated and buggy. I would happily use them if I knew a way to do it while keeping code simple. > When we have distinct structures, signatures and functors we can easily understand how they are supposed to be used Yet Javascript has neither of those. > If you mean that mutating values should be avoided No, I am ok with mutable values.
- chriswarbo 10y ago
  > I am trying to write a code that is readable and maintainable instead of building complex abstractions. My point is that what's "readable and maintainable" depends on the language; especially on what facilities it provides, and to some extent community consensus (what's 'idiomatic'). Javascript's main facilities are first-class functions with lexical scope, lightweight key/value mappings (which it calls "objects") and prototypical inheritance between those objects. Java's main facilities are classes with properties and methods; whilst it's recently gained first-class functions, most Java code has been written without them, and they'll always be in competition with classes+methods (e.g. look at all of the APIs which use single-method classes, like "Comparator"). These are very different, so what's readable/maintainable will differ in each. For example, Javascript's objects are so lightweight that it's idiomatic to write them inline exactly where they're needed, like 'foo({bar: function() { ... }, ...})'. In idiomatic Java, such objects should be instances of a class, which should either be global or else implement a global interface. Since global class/interface declarations require standalone files, our declarations end up very far away from the use site; this prevents us accessing the use-site's scope and puts us under more pressure to make it descriptive, generic, reusable, etc. > Yet Javascript has neither of those. ES6 has a module system, Java has its "package" system. Trying to apply SML practices to either is a bad idea, just as trying to apply Java OO practices to JS is a bad idea, or trying to apply Lisp macro practices to C is a bad idea.