My position on private symbols.
My position on classes is and has always been that classes are worth
introducing into the language *only* if they give us, or can be used
with, an affordable means for true object encapsulation. Assuming
Allen is right about what actual implementors will do (which I find
plausible) then WeakMaps are not that means. Given other discussions,
I am confident that the objects-as-closures pattern will not become
efficient either -- it is likely to continue to cost an allocation per
method per instance as its semantics naively suggests. So of the
options practically on the table, I think private symbols are the only
workable choice. If this is correct, then I consider private symbols
to be a requirement. Am I missing anything?
On Wed, Jan 16, 2013 at 12:25 PM, Brandon Benvie
<bran...@brandonbenvie.com> wrote:
> Indeed, I used SES as a kind of template for this theoretical future
> framework faced with the wcenarios. It was a response to the idea that
> private symbols are primarily valuable for a SES type use case where
> security is paramount, versus regular encapsulation which is handled
> adequately by unique symbols.
>
>
> On Wednesday, January 16, 2013, Mark S. Miller wrote:
>>
>> On Wed, Jan 16, 2013 at 11:47 AM, Brandon Benvie
>> <bran...@brandonbenvie.com> wrote:
>> > To compare the various scenarios, this is what (I believe) it looks like
>> > for
>> > SES. In ES5, SES currently censors gOPN I believe, in order to implement
>> > the
>> > equivalent of private keys and/or WeakMap.
>>
>> SES includes all API defined in std ES5 including gOPN. On platforms
>> without built-in WeakMaps, SES does virtualize gOPN as part of its
>> emulation of WeakMaps, but that should be completely invisible to the
>> SES user. SES currently only seeks to be like ES5+WeakMaps. It does
>> not currently attempt to emulate private or unique symbols.
>>
>>
>> > Given an ES6 runtime environment
>> > that only supported unique symbols, it would have to censor getOwnKeys
>> > and
>> > filter symbols if they were present in a blacklist Set. Given an ES6
>> > runtime
>> > environment with private symbols, SES wouldn't have to censor either.
>>
>>
>> --
>> Cheers,
>> --MarkM
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
