3 ms·
Even though OP is about Coffeescript (which != JS), I think my comment is still relevant. This is from an older SO post I made[0]: (The context is immediately
by dvt 13y ago
Even though OP is about Coffeescript (which != JS), I think my comment is still relevant.
This is from an older SO post I made[0]: (The context is immediately invoked function expressions) IIFEs are often confusing to read and personally, I have no idea why they have become so mainstream. I think code should be easy to read and concise. Attempting to simulate language behavior that is not part of the language specification is often-times a very dumb idea.
For example, JavaScript does not support multiple inheritance, polymorphism, or many other interesting paradigms. So a lot of times, we see people trying to create these crazy ways of sorta'-kinda' having polymorphism or private members, etc in JS. I think this is a mistake.
[0]: http://stackoverflow.com/questions/12078812/how-to-choose-oo-design-patterns-for-javascript/12081084#12081084 http://stackoverflow.com/questions/12078812/how-to-choose-oo...
- ep103 13y agoI completely agree, except for the private methods portion. I personally find (function(){ //implementation methods and variables return{ //public methods }; })() to be far easier to read than var myObject = { //A random mix of public and implementation details }; Though I will admit that my main reason for believing the above, is that when you work with developers who do not spent much time in JS, and they realize they have to write something complicated without private methods, they tend to write either monstrously long public methods as a result, or write as normal and litter the interface of the object, thereby completely breaking SOLID. The first method above avoids that problem.