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 > <[email protected] <javascript:;>> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
