6 ms·

No. Just no. Simpler is better, especially if there are no real drawbacks. I think this remark about entry level developers is snobistic. I have an open mind

No. Just no. Simpler is better, especially if there are no real drawbacks. I think this remark about entry level developers is snobistic. I have an open mind and I am always willing to learn. Yet you just dismiss my approach without providing solid argumentation. The only real argument against the minimalist approach is performance and I was well aware of this when I wrote the article. And yes, prototypes are more difficult, not just for entry level developers, let's see why: * you cannot use previous OOP experience (aka 'transfer') * there are MANY ways to do OOP using prototypes (functions,direct prototyping,__proto__) vs ONE * 'this' has different meanings depending on context -> requires you to process contextual information * prototypes make existing objects unreliable -> requires prior knowledge about libraries and APIs (leaky abstraction) * building an object with prototypes requires far more mental steps: you have to know about objects, functions but also about the prototype chain, the hidden prototype property (why?), the logic behind the new keyword etc. If prototypes had been implemented in a very consistent way (without the new-keyword and only using __proto__) I would have advocated prototypes instead of literals. On top of this, many different 'sugar' solutions exist, most of them incompatible. Advantages of the minimalist approach: * conforms to established industry and business standards in OOP * requires less knowledge about language details, this leaves much more room to focus on application logic and design * very transparent, no sugar code (beget) or libraries required * neat code: methods are grouped together * allows to implement well known design patterns easily * protection against corruption of existing objects * no this, that or self variables And all you are saying is: it's too easy, it must be for entry level developers. I mean... what is this about? Are we trying to build great products or is this some kind of puzzle contest? If you like complexity so much I recommend to write your next project in malbolge (http://en.wikipedia.org/wiki/Malbolge http://en.wikipedia.org/wiki/Malbolge).

russfrank 15y ago
Your approach is essentially the 'module pattern'. This article describes some other reasons you might not want to use it: http://snook.ca/archives/javascript/no-love-for-module-pattern http://snook.ca/archives/javascript/no-love-for-module-patte... I lead a somewhat large (~10000 sloc) project which uses the module pattern everywhere. I think the best argument against the module pattern is the difficulty of debugging. I can no longer just pop open a console and inspect objects. Responses to your individual points: >> * you cannot use previous OOP experience While unfortunate I believe this is largely unavoidable. Javascript's object system is not 'classical' inheritance. The module pattern, however, is also not 'classical' inheritance. Regardless of OOP technique, the New Javascript Programmer must learn about the object system. >> * there are MANY ways to do OOP using prototypes There are also many forms of the module pattern. You just showed me another one I hadn't seen before. Then there's immediately invoking function expressions, which some people like to do like this (function () { var exports = {}; return exports; })()); and others like to do like this !function() { var private = 4; return { getPrivate: function () { return private; }; }(); >> * 'this' has different meanings depending on context Can't argue against this one. >> * prototypes make existing objects unreliable -> requires prior knowledge about libraries and APIs (leaky abstraction) I'm not sure I see the argument here. >> * building an object with prototypes requires far more mental steps: .. I'm not sure you really need to know about all of these things.. but sure, prototypal inheritance is confusing to those with a 'classical' background. As for the advantages: >> * conforms to established industry and business standards in OOP I don't see why prototypal inheritance does not. If you look at CoffeeScript, it even appears classical. >> * requires less knowledge about language details I have to disagree here. Explaining object literals and immediately invoking functions and closure isn't all that easy. >> * very transparent, no sugar code or libs required That's true. >> * neat code There's no reason why new/this/prototypal code can't be neat! >> * design patterns blah blah There's no reason why new/this/prototypal code can't do design patterns! >> * protection against corruption I've never seen this as an issue in practice, but my code isn't running in the browser. Unless you're talking about protection from other programmers, in which case, I would quote Guido van Rossum. >> * no this, that or self variables Could be a good thing or a bad thing. This means that you have to know what's public and what isn't, rather than it being explicit. I rather like it when things are explicit. Sometimes we sacrifice a little simplicity for a little flexibility or a little efficiency. Sometimes it's worth it, sometimes it isn't.
- gabordemooij 15y ago
  Okay fine. Then tell me how do you write javascript OOP; what's your favourite way. Can you give me an example of your code? I am willing to admit mistakes but I have to be convinced.
  - MatthewPhillips 15y ago
    I just use Object.create[1]. Constructor functions give the illusion of classical inheritance but JavaScript doesn't have classical inheritance and I think it's best to simply break the notion off from your brain by not using stuff that makes JS appear to be something it is not. JavaScript uses prototypes. Prototypes or just objects from which you derive other objects. Object.create makes this very obvious. Under the hood you are still using prototypes in the same way as you would by using constructor functions you just don't have to worry about the Constructor.prototype object as it is abstracted from view. The second biggest problem with the method you are using (after performance/memory consumption) is not having access to either instanceof or isPrototypeOf. If you are doing anything complicated having access to one of those two can by crucial. [1]https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/create https://developer.mozilla.org/en/JavaScript/Reference/Global...
    - gabordemooij 15y ago
      Object.create does not even work in most browsers! So you cannot even use the preferred solution in todays most popular browsers: http://www.w3counter.com/globalstats.php?year=2011&month=12 http://www.w3counter.com/globalstats.php?year=2011&month... http://kangax.github.com/es5-compat-table/ http://kangax.github.com/es5-compat-table/ and you really dont expect anyone to write clunky property descriptors like this?? https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/defineProperty https://developer.mozilla.org/en/JavaScript/Reference/Global...
      - MatthewPhillips 15y ago
        You shouldn't be defensive, I'm just another programmer like you. I (and hopefully others in this thread) just want to share my own experiences and let you know what options are out there. Feel free not to use them, find your own preferences. The article I linked to gives a shim for Object.create if you need to target IE7/IE8. All other browsers already support it, including all mobile browsers. Yeah, the descriptor object is, in my opinion, a design mistake when they did Object.create. Modifying property descriptors is an exceptional need, and there are other ways to do it when you have that need (Object.defineProperty and Object.defineProperties). However, that's an optional parameter. You don't need to use it. You can just define properties like you normally would to an object. For example: var one = Object.create(null); one.foo = 'bar'; var two = Object.create(one); two.fee = 'fi fo fum'; If you want extra sugar to make the definition of own properties more eloquent (by having them in a single object literal) there are libraries/snippets that will do that for you. Here is one I wrote (which is just a very small snippet around Object.create): http://code.matthewphillips.info/thingjs/ http://code.matthewphillips.info/thingjs/
stephenr 15y ago
> No. Just no. Simpler is better, especially if there are no real drawbacks. Your claim of "no real drawbacks" is very much your opinion, nothing more. > Yet you just dismiss my approach without providing solid argumentation I've made several other comments on this item. > you cannot use previous OOP experience Shock horror, a developer needs to learn JavaScript before writing JavaScript. This is a positive not a negative. There are already too many "developers" who write javascript without understanding it. > there are MANY ways to do OOP using prototypes (functions,direct prototyping,__proto__) vs ONE your example of "many ways" is misleading: it's not "functions" or "direct prototyping" - you assign functions to a constructor's prototype, and they become instance methods. __proto__ is non-standard, and no developer worth working with would use it for creating "classes". There are also MANY ways to create "classes" using object literals - the article linked just gives one example of this. > 'this' has different meanings depending on context -> requires you to process contextual information you're making a mountain out of a molehill. > prototypes make existing objects unreliable -> How so? > requires prior knowledge about libraries and APIs (leaky abstraction) No more than an object literal with methods attached to it. > building an object with prototypes requires far more mental steps: you have to know about objects, functions but also about the prototype chain, the hidden prototype property (why?), the logic behind the new keyword etc. Yes, it's so horrible that developers using a language need to have some knowledge of that language before writing more than basic code, isn't it? > If prototypes had been implemented in a very consistent way (without the new-keyword and only using __proto__) I would have advocated prototypes instead of literals you still haven't actually given any reason the new operator is "bad". and you keep mentioning __proto__ which makes me think you don't understand the language at all. __proto__ is a non-standard property that some implementations expose > On top of this, many different 'sugar' solutions exist, most of them incompatible. You don't need "sugar" at all - just a constructor function definition, any methods for the prototype and then as many calls to instantiate objects as required. > conforms to established industry and business standards in OOP buzzwords and "make the boss happy" phrases mean nothing here. > requires less knowledge about language details, this leaves much more room to focus on application logic and design if the developer doesn't understand javascript, which OOP pattern you use is the least of your worries. > very transparent, no sugar code (beget) or libraries required as I said, no sugar or libraries are required for prototype "classes" - it's part of the language you are choosing to ignore. > neat code: methods are grouped together How is this different to assigning methods to a constructor's prototype? > allows to implement well known design patterns easily this is a pattern in and of itself, what are you talking about? > no this, that or self variables a lack of "this" is not an advantage - you mentioned earlier about not being able to re-use previous OOP experience, then argue that not using a standard OOP concept ("this" in instance methods) is a good thing?? Make up your mind! > And all you are saying is: it's too easy, it must be for entry level developers. No, I said "simpler is not always better". Your approach ignores huge parts of the way JavaScript works because "it's too hard". It's nothing to do with puzzle contests or ridiculous languages - it's about learning to use a language to it's full potential, rather than sticking your head in the sand and saying "it's too hard, so I'm not going to do it!".

russfrank 15y ago

Your approach is essentially the 'module pattern'. This article describes some other reasons you might not want to use it: http://snook.ca/archives/javascript/no-love-for-module-pattern http://snook.ca/archives/javascript/no-love-for-module-patte... I lead a somewhat large (~10000 sloc) project which uses the module pattern everywhere. I think the best argument against the module pattern is the difficulty of debugging. I can no longer just pop open a console and inspect objects. Responses to your individual points: >> * you cannot use previous OOP experience While unfortunate I believe this is largely unavoidable. Javascript's object system is not 'classical' inheritance. The module pattern, however, is also not 'classical' inheritance. Regardless of OOP technique, the New Javascript Programmer must learn about the object system. >> * there are MANY ways to do OOP using prototypes There are also many forms of the module pattern. You just showed me another one I hadn't seen before. Then there's immediately invoking function expressions, which some people like to do like this (function () { var exports = {}; return exports; })()); and others like to do like this !function() { var private = 4; return { getPrivate: function () { return private; }; }(); >> * 'this' has different meanings depending on context Can't argue against this one. >> * prototypes make existing objects unreliable -> requires prior knowledge about libraries and APIs (leaky abstraction) I'm not sure I see the argument here. >> * building an object with prototypes requires far more mental steps: .. I'm not sure you really need to know about all of these things.. but sure, prototypal inheritance is confusing to those with a 'classical' background. As for the advantages: >> * conforms to established industry and business standards in OOP I don't see why prototypal inheritance does not. If you look at CoffeeScript, it even appears classical. >> * requires less knowledge about language details I have to disagree here. Explaining object literals and immediately invoking functions and closure isn't all that easy. >> * very transparent, no sugar code or libs required That's true. >> * neat code There's no reason why new/this/prototypal code can't be neat! >> * design patterns blah blah There's no reason why new/this/prototypal code can't do design patterns! >> * protection against corruption I've never seen this as an issue in practice, but my code isn't running in the browser. Unless you're talking about protection from other programmers, in which case, I would quote Guido van Rossum. >> * no this, that or self variables Could be a good thing or a bad thing. This means that you have to know what's public and what isn't, rather than it being explicit. I rather like it when things are explicit. Sometimes we sacrifice a little simplicity for a little flexibility or a little efficiency. Sometimes it's worth it, sometimes it isn't.

gabordemooij 15y ago
Okay fine. Then tell me how do you write javascript OOP; what's your favourite way. Can you give me an example of your code? I am willing to admit mistakes but I have to be convinced.
- MatthewPhillips 15y ago
  I just use Object.create[1]. Constructor functions give the illusion of classical inheritance but JavaScript doesn't have classical inheritance and I think it's best to simply break the notion off from your brain by not using stuff that makes JS appear to be something it is not. JavaScript uses prototypes. Prototypes or just objects from which you derive other objects. Object.create makes this very obvious. Under the hood you are still using prototypes in the same way as you would by using constructor functions you just don't have to worry about the Constructor.prototype object as it is abstracted from view. The second biggest problem with the method you are using (after performance/memory consumption) is not having access to either instanceof or isPrototypeOf. If you are doing anything complicated having access to one of those two can by crucial. [1]https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/create https://developer.mozilla.org/en/JavaScript/Reference/Global...
  - gabordemooij 15y ago
    Object.create does not even work in most browsers! So you cannot even use the preferred solution in todays most popular browsers: http://www.w3counter.com/globalstats.php?year=2011&month=12 http://www.w3counter.com/globalstats.php?year=2011&month... http://kangax.github.com/es5-compat-table/ http://kangax.github.com/es5-compat-table/ and you really dont expect anyone to write clunky property descriptors like this?? https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/defineProperty https://developer.mozilla.org/en/JavaScript/Reference/Global...
    - MatthewPhillips 15y ago
      You shouldn't be defensive, I'm just another programmer like you. I (and hopefully others in this thread) just want to share my own experiences and let you know what options are out there. Feel free not to use them, find your own preferences. The article I linked to gives a shim for Object.create if you need to target IE7/IE8. All other browsers already support it, including all mobile browsers. Yeah, the descriptor object is, in my opinion, a design mistake when they did Object.create. Modifying property descriptors is an exceptional need, and there are other ways to do it when you have that need (Object.defineProperty and Object.defineProperties). However, that's an optional parameter. You don't need to use it. You can just define properties like you normally would to an object. For example: var one = Object.create(null); one.foo = 'bar'; var two = Object.create(one); two.fee = 'fi fo fum'; If you want extra sugar to make the definition of own properties more eloquent (by having them in a single object literal) there are libraries/snippets that will do that for you. Here is one I wrote (which is just a very small snippet around Object.create): http://code.matthewphillips.info/thingjs/ http://code.matthewphillips.info/thingjs/

stephenr 15y ago

> No. Just no. Simpler is better, especially if there are no real drawbacks. Your claim of "no real drawbacks" is very much your opinion, nothing more. > Yet you just dismiss my approach without providing solid argumentation I've made several other comments on this item. > you cannot use previous OOP experience Shock horror, a developer needs to learn JavaScript before writing JavaScript. This is a positive not a negative. There are already too many "developers" who write javascript without understanding it. > there are MANY ways to do OOP using prototypes (functions,direct prototyping,__proto__) vs ONE your example of "many ways" is misleading: it's not "functions" or "direct prototyping" - you assign functions to a constructor's prototype, and they become instance methods. __proto__ is non-standard, and no developer worth working with would use it for creating "classes". There are also MANY ways to create "classes" using object literals - the article linked just gives one example of this. > 'this' has different meanings depending on context -> requires you to process contextual information you're making a mountain out of a molehill. > prototypes make existing objects unreliable -> How so? > requires prior knowledge about libraries and APIs (leaky abstraction) No more than an object literal with methods attached to it. > building an object with prototypes requires far more mental steps: you have to know about objects, functions but also about the prototype chain, the hidden prototype property (why?), the logic behind the new keyword etc. Yes, it's so horrible that developers using a language need to have some knowledge of that language before writing more than basic code, isn't it? > If prototypes had been implemented in a very consistent way (without the new-keyword and only using __proto__) I would have advocated prototypes instead of literals you still haven't actually given any reason the new operator is "bad". and you keep mentioning __proto__ which makes me think you don't understand the language at all. __proto__ is a non-standard property that some implementations expose > On top of this, many different 'sugar' solutions exist, most of them incompatible. You don't need "sugar" at all - just a constructor function definition, any methods for the prototype and then as many calls to instantiate objects as required. > conforms to established industry and business standards in OOP buzzwords and "make the boss happy" phrases mean nothing here. > requires less knowledge about language details, this leaves much more room to focus on application logic and design if the developer doesn't understand javascript, which OOP pattern you use is the least of your worries. > very transparent, no sugar code (beget) or libraries required as I said, no sugar or libraries are required for prototype "classes" - it's part of the language you are choosing to ignore. > neat code: methods are grouped together How is this different to assigning methods to a constructor's prototype? > allows to implement well known design patterns easily this is a pattern in and of itself, what are you talking about? > no this, that or self variables a lack of "this" is not an advantage - you mentioned earlier about not being able to re-use previous OOP experience, then argue that not using a standard OOP concept ("this" in instance methods) is a good thing?? Make up your mind! > And all you are saying is: it's too easy, it must be for entry level developers. No, I said "simpler is not always better". Your approach ignores huge parts of the way JavaScript works because "it's too hard". It's nothing to do with puzzle contests or ridiculous languages - it's about learning to use a language to it's full potential, rather than sticking your head in the sand and saying "it's too hard, so I'm not going to do it!".