possible excessive proxy invariants for Object.keys/etc??

David Bruant bruant.d at gmail.com
Wed Nov 21 11:13:12 PST 2012


Le 21/11/2012 17:37, Allen Wirfs-Brock a écrit :
>
> On Nov 21, 2012, at 1:55 AM, David Bruant wrote:
>
>> Le 21/11/2012 01:06, Allen Wirfs-Brock a écrit :
>>>>>
>>>>>>     b) that all the elements of the result are Strings
>>>>>
>>>>>     And presumably Symbols.  We have to also accommodate Symbols,
>>>>>     at least for getOwnPropetyNames.  Regardless, why is this
>>>>>     important?  More below...
>>>>>
>>>>>
>>>>> Same argument as above.
>>>>>
>>>>> I recall there was some concern about symbols showing up in 
>>>>> existing reflection methods like Object.getOwnPropertyNames. Not 
>>>>> sure how that got resolved. It's basically touching upon the same 
>>>>> issue of whether we can change the return type of existing methods.
>>>
>>> I'm assuming we are excluding symbols from [[Enumerate]] and [[Keys]]
>> Why so? I would assume unique symbols to show up for these.
>
> I believe that the POR is that Symbol keys are never enumerated (even 
> if associated with a the property attribute that has [[Enumerable]]: 
> true).  I suppose a proxy could violate that invariant (I wouldn't 
> want to actively enforce it) but would be a buggy proxy.
What does "POR" mean?

>
>>
>>> so it is only [[GetOwnPropertyNames]] that have this concern.
>> and of course non-enumerable unique symbols for this operation.
>
> ie, private Symbols
>
> (private Symbols, not only are always non-enumerable.  They are never 
> reflected by primitive operation unless the symbol value is explicitly 
> presented as an argument.  You can getOwnPropertyDescriptor using a 
> private symbol, but getOwnPropertyNames never includes them)
>
>> For both case, I think returning unique symbols work as long as ES6 
>> doesn't consider that objects have built-in unique-symboled 
>> properties (because that could probably break existing code).
>
> I assume by unique-symbol you mean the samething as private symbol.
Indeed, I meant private here, sorry for the mistake.

> The above will hold, assuming we make @@interator, @@toStringTag, 
> @@hasInstance, etc. private symbols.  While they need to be 
> well-known, I don't see any reason why they shouldn't also be private.
+1

> Good point about the white lists,  that changes my mind about making 
> the built-in symbols private. I think I'd prefer to take the risks of 
> alternative  1 rather than forcing proxy writers to deal with them in 
> white lists.  I think there is probably a greater risk of people 
> messing up whitelisting than that there will be campat. issues with gOPN.
If the proxy module provides a constructor like 
BuiltInPrivateNamesWeakSet, things could be fine:

     var whitelist = new BuiltInPrivateNamesWeakSet();
     whitelist.add(...) // adding user generated private names if applicable
     var p = new Proxy(target, handler, whitelist);

The name I'm proposing is a bit long, but that would solve the built-in 
private name micro management problem elegantly enough as far as I'm 
concerned. It's also future-proof in the sense that if new built-in 
private names are added, the weakset will do the right thing in updated 
environments.
If people want to build the weakset manually, they would be free to do 
so, but at least, the helper would do the annoying part on behalf of the 
user.
We can consider that if the third argument is omitted, all built-in 
private names pass. That sounds like a good useful default.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121121/89083cf4/attachment-0001.html>


More information about the es-discuss mailing list