New private names proposal

Brendan Eich brendan at
Tue Dec 21 16:25:15 PST 2010

On Dec 21, 2010, at 4:01 PM, Oliver Hunt wrote:

> 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).

Why does your expectation differ here compared to the following:

MyAwesomeThing.prototype.myCoolFunction = function() {
   var cachedHotness = gensym();
   if (!this[cachedHotness])
       this[cachedHotness] = doExpensiveThing(this)
   return this[cachedHotness];

Is it because |private cachedHotness;| does not "look generative"?

> 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.

You mean non-string property names, right?

But what is an array index, then? uint32 is not a type in the language. Would proxy[3.14] really pass a double through?

Array elements are named by a weird uint32 index name, with consequences on 'length' (but only up to 2^32 - 1 for length). I don't think passing the property name through uncoerced helps, unless you assume a normalizing layer above all name-based operations that specializes to index-names per Array's uint32 magic weirdness.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list