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.

/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to