6 ms·

I dont use new, prototype and this because I find them confusing. While it may be trendy and cool to claim that this is just me being stupid and you being smart

• TazeTSchnitzel 15y ago
  Whilst I personally don't like using constructors and prototypal inheritance, I think it would be best if you try to understand something before dismissing it. Edit: Just because you don't understand something or refuse to understand it does not mean you should dismiss it.
  • gabordemooij 15y ago
    Why do you assume I don't understand prototypical inheritance? To me this highlights part of the problem of our community. Once you choose not to use a certain feature you are being regarded as stupid. What ever happened to the KISS principle? http://en.wikipedia.org/wiki/KISS_principle http://en.wikipedia.org/wiki/KISS_principle The minimal approach is simpler. Try explaining prototype OOP and minimal OOP to a newcomer and see for yourself. Software complexity is a result of evolution; as the code base grows it becomes more complex, there is no need for us to add it beforehand.
    • stephenr 15y ago
      Simpler isn't always better. If your entire team is entry level developers who think jquery is magic, maybe you have a point, but frankly I'd rather work alone that with people that dense.
      • gabordemooij 15y ago
        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.
    • stephenr 15y ago
      > Why do you assume I don't understand prototypical inheritance? Because you said: > I dont use new, prototype and this because I find them confusing