New private names proposal

[Oliver Hunt]

On Dec 21, 2010, at 4:25 PM, Brendan Eich wrote:

> 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"?

Yes.  The fact that we know how they are implemented behind the scenes may make the non-obvious appear obvious.

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

Yes

> 
> But what is an array index, then? uint32 is not a type in the language. Would proxy[3.14] really pass a double through?
Yes, I would expect no coercion of any non-object.  The reason for disallowing objects is safety afaik, those arguments don't apply to non-objects.

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

And people are welcome to implement those semantics if they so desire.  I just see no reason to artificially limit behaviour.  Especially when the alternative is to say that the argument to the trap "will be a string, except in this case that you don't expect".  I think it's better to be consistent and simply allow all non-objects through.  This allows better perf for some use cases, and to my mind simpler semantics in the face of things like private names.

> /be
--Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101221/372f8e1b/attachment-0001.html>