brandon at brandonbenvie.com
Wed Jan 16 12:25:40 PST 2013
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
> > To compare the various scenarios, this is what (I believe) it looks like
> > SES. In ES5, SES currently censors gOPN I believe, in order to implement
> > 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
> > filter symbols if they were present in a blacklist Set. Given an ES6
> > environment with private symbols, SES wouldn't have to censor either.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss