On Mon, Jan 28, 2013 at 11:10 AM, David Bruant <bruan...@gmail.com> wrote:
> Hi Tom,
>
> Thanks for this summary.
> About the first proposal and getting rid of the whitelist, indeed, the
> whitelist was here to tell about known symbols to avoid leakage. If private
> symbols pierce proxies, the whitelist has no purpose any longer.
>
> I don't understand why problem B isn't solved with the first proposal.
> Since the proxy is pierced, access to private symbol'ed properties don't
> trap and the proxy can't throw on access (since it's not trapped).
> If I'm misunderstanding the proposal, could you show an example, under the
> unconditional forwarding proposal in which the problem B can be reproduced.
>
>
> The second proposal reminds me a bit of an evolution of the first proxy
> design in which each proxy would have its own storage for invariant checks.
> Since a forwarding proxy was the main use case and already had a storage
> area (the target), this led to the second design "direct proxy" in which
> both storages would be merged in the target.
> By analogy, the natural evolution of the second proposal would be the
> first proposal.
>
The natural evolution of the second proposal is to use WeakMaps where we
would otherwise use private symbols, and get rid of the notion of private
symbol per se.
Modulo naming, Kevin's unified proposal is equivalent to this. To illustrate
function KevinsSymbol() {
var result = WeakMap();
result.__proto__ = null; // no own properties and inherits no properties
return Object.freeze(result);
}
(Given) var call = Function.prototype.call;
var kevinsGet = call.bind(WeakMap.prototype.get);
var kevinsSet = call.bind(WeakMap.prototype.set);
>
> David
>
>
> Le 28/01/2013 19:45, Tom Van Cutsem a écrit :
>
> I just wrote up a strawman on the wiki to summarize the recent debates
>> about the interaction between proxies and private symbols:
>>
>> http://wiki.ecmascript.org/**doku.php?id=strawman:proxy_**
>> symbol_decoupled<http://wiki.ecmascript.org/doku.php?id=strawman:proxy_symbol_decoupled>
>>
>> The page actually lists two proposals, out of which I prefer the second
>> one.
>>
>> If I forgot some benefits/drawbacks of either approach, please speak up.
>> Thanks.
>>
>> Cheers,
>> Tom
>>
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
