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