New private names proposal
Oliver Hunt
oliver at apple.com
Tue Dec 21 16:01:33 PST 2010
Just giving my feedback to this (so it's recorded somewhere other than my head).
I find the apparent necessity of conflating syntax and semantics irksome, i'd much rather that there be two distinct discussions one of syntax and the other for semantics of soft-fields, private names, gremlins, etc (or whatever this general concept ends up being called)
That said I don't really like the private names syntax, mostly for reasons others have bought up already, but one case I don't recall seeing is something that I think will lead to surprise on the part of developers. Say i have a piece of code:
function MyAwesomeThing() {
....
}
MyAwesomeThing.prototype.myCoolFunction = function() {
if (!this._myCachedHotness)
this._myCachedHotness = doExpensiveThing(this)
return this._myCachedHotness;
}
I see this nifty private names feature, and say "cool! now i can make my cache super secret!" and do:
MyAwesomeThing.prototype.myCoolFunction = function() {
private cachedHotness;
if (!this.cachedHotness)
this.cachedHotness = doExpensiveThing(this)
return this.cachedHotness;
}
I would _expect_ this to work. That's what the syntax makes me think. But it won't work because 'cachedHotness' is going to be different on every call (at least to my reading).
I am not trying to argue that making the above work is impossible -- you just need to use a few closures to get everything into the right place. But it is contrary to what I might expect or want.
wrt. proxies, I still think that we should just allow all non-objects property names to transfer through uncoerced. It would solve the problem of communicating private names to a proxy and allow efficient array-like implementations.
--Oliver
More information about the es-discuss
mailing list