">thing: ->
> @_thing ?= new Thing<p>..is … irritating."<p>So... having one sigil to distinguish a class variable isn't irritating, but another for a variable accessed by an accessor method is. Got it.<p>> It’s tempting to presume that this is a ‘feature’ of prototypal inheritance<p>Why would this be tempting? As the author points out, there are prototype-based languages that avoid it, and you could remove prototypes from JavaScript and still encounter the issue.<p>> we’re not writing Java. We’re in a highly dynamic language. We want nice things. Or, we could create setters and getters using the new ES5 syntax – but that’s not available everywhere (pre-IE9, for instance), and, I would argue, is too unwieldy to apply as a rule.<p>You want an easy way to create accessors? OK:<p><pre><code> function prop(name,gNs) {
function undef(v) { return typeof v == 'undefined'; }
var _name = '_' + name, get = gNs && gNs.get, set = gNs && gNs.set;
if(get && set) return function (x) {
return undef(x) ? get.call(this,this[_name]) : (this[_name] = set.call(this,x), this);
}
if(get && !set) return function (x) {
return undef(x) ? get.call(this,this[_name]) : (this[_name] = x, this);
}
if(!get && set) return function (x) {
return undef(x) ? this[_name] : (this[_name] = set.call(this,x), this);
}
return function (x) {
return undef(x) ? this[_name] : (this[_name] = x, this);
}
}
</code></pre>
You're welcome. Use it like so:<p><pre><code> obj = {
thing: prop('thing')
}
</code></pre>
when you want your accessors to do something other than getting/setting:<p><pre><code> obj = {
thing: prop('thing', {
get: function () { return foobarled(this._thing); },
set: function (x) { this._thing = unfoobarled(x); }
})
}
</code></pre>
> What we’re really saying is ‘everything is a hashtable’. Is that a good thing?<p>I'm more sympathetic to this criticism. There's times when the fact that everything can have arbitrary properties is convenient, but it does place some burden on the developer to pay attention.<p>Then again, I think that's a general charge to which any highly dynamic language is going to have to answer on some point or another. And if you're prone to typing `[]` when you mean `{}` (understandable if you've come from a language where they have different meanings), it's possible you should do the more conspicuous thing and use `new Array` and `new Object` instead.<p>> Nothing is an object<p>No. What the author is really talking about that by default, there aren't "methods" with class-bound scope. Just functions whose `this` scope is dynamic but does live by some pretty understandable rules.<p>> _missing<p>Missing method's sometimes convenient, and there are occasions when I miss it in JS too, but it's much rarer than I once would have thought. Use cases in languages where functions are less often let out on their own tend to get taken care of differently in languages where they do.<p>> I’ve yet to hear anyone convincingly argue that JavaScript’s version of OOP offers anything in addition to or distinction from more traditional versions;<p>"convincingly"<p>Convincing who?