Private symbols vs property attributes

David Bruant bruant.d at gmail.com
Sun Feb 10 09:12:21 PST 2013


Le 10/02/2013 08:07, Brendan Eich a écrit :
> Allen Wirfs-Brock wrote:
>> Note that the enumerable attribute really only affects for-in 
>> enumeration (and Object.keys), neither of which enumerates symbols 
>> anyway.  That, means that the enumerable attribute really has has no 
>> current meaning for symbol keyed properties.  That means we could 
>> probably reinterpret the enumerable attribute as a "private" 
>> attribute for such symbol keyed properties.
>
> Groovy.
>
> But the private-as-attribute idea still seems to require an access 
> control check, which makes it less secure from an OCap perspective and 
> experience, compared to symbols as capabilities.
I'm not sure I understand your concern.
Under Andreas proposal, a symbol would remain an unforgeable token. The 
only thing that changes is how the symbol is shared. In the proposal 
being discussed setting private:false in the property descriptor would 
be a way to share a symbol. That's less direct than handing access to 
the symbol only, but that's a very explicit way anyway, so I don't see a 
problem from an ocap perspective.
That said, to force the author to be explicit about sharing symbols 
indirectly through reflection, private:true should probably be the 
default when doing "obj[symb] = 34".

David


More information about the es-discuss mailing list