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