">thing: -> > @_thing ?= new Thing ..is … irritating." So... having one sigil to distinguish a class variable isn't irritating, but another for a variable

">thing: -> > @_thing ?= new Thing ..is … irritating." 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. > It’s tempting to presume that this is a ‘feature’ of prototypal inheritance 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. > 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. You want an easy way to create accessors? OK: 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); } } You're welcome. Use it like so: obj = { thing: prop('thing') } when you want your accessors to do something other than getting/setting: obj = { thing: prop('thing', { get: function () { return foobarled(this._thing); }, set: function (x) { this._thing = unfoobarled(x); } }) } > What we’re really saying is ‘everything is a hashtable’. Is that a good thing? 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. 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. > Nothing is an object 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. > _missing 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. > 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; "convincingly" Convincing who?