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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
