3 ms·
Much more concise. I was curious on Jeremy's view on getters, setters in JS - can be summed up as it is "impossible to reason about the side-effects of your co
by jonmc12 15y ago
Much more concise. I was curious on Jeremy's view on getters, setters in JS - can be summed up as it is "impossible to reason about the side-effects of your code" (aside from the fact that it also does not work on IE).
http://irclogger.com/.coffeescript/2011-01-05#1294280074 http://irclogger.com/.coffeescript/2011-01-05#1294280074
How is that different than the validation / error handling in the model set method in Backbone.js (in that they can run arbitrary code)? Is it just the distinction of side-effects in the language vs the framework?
Also, why should a = obj.b need to be any more predicable than a = obj.b()?
It seems like there are benefits to using getters / setters (ie, http://ejohn.org/blog/javascript-getters-and-setters/ http://ejohn.org/blog/javascript-getters-and-setters/), and I actually think the syntax is cleaner "get firstName" vs "getFirstName". Curious to understand more about the objection.
- tolmasky 15y agoIt's simply interesting that this: for (key in hash) hash[key] = null; May or may not call a bunch of functions. It could turn out to be a debugging nightmare.
- skrebbel 15y agoThere are many popular languages for which this is the case (C#, Ruby, PHP even), and I haven't heard anyone panic yet. The deal is that if you implement a property getter, you promise no side effects and fast execution (for some value of "fast"). If you don't do this, your code is broken.
- ootachi 15y agoIt always did in JavaScript from day one, given host objects.