Le 15/01/2013 20:32, Tom Van Cutsem a écrit :
2013/1/10 Brendan Eich <[email protected] <mailto:[email protected]>>
David Bruant wrote:
[Cc'ing Tom and Mark to be sure there is agreement on what I'm
claiming in this message]
Le 10/01/2013 22:10, Brendan Eich a écrit :
Nathan Wall wrote:
Brendan Eich:
No, not if the symbol is not in the whitelist.
Zero information leak is
required.
That's good news too. Objection withdrawn.
Maybe I gave up too easy :). Is the
`unknownPrivateSymbol` trap called? What's the
rationale for this trap?
I just wrote that the trap is not even called if the
symbol is not in the whitelist passed in when the proxy is
created.
No, the unknownPrivateSymbol trap is called when the symbol is
not in the whitelist, so, as Nathan fears, a malicious proxy
could throw and cancel the access to the private property.
Of course, and my description was for a "knownPrivateSymbol" trap!
Shows how much I know :-P. Waiting to hear from Tom on this.
Thanks to Nathan for being a squeaky wheel.
The "unknownPrivateSymbol" trap would indeed be called when a private
symbol not on the proxy's whitelist is encountered.
As far as I recall, the purpose of the trap was to allow a membrane or
revocable proxy to explicitly abort accesses involving such private
symbols. The point being that if a membrane can't abort such accesses,
then collaborators on both sides of the membrane could circumvent the
membrane by communicating via a previously agreed upon private symbol.
Yes, we've discussed that in length with Nathan Wall :-)
I think the return true/false protocol should be replaced by a
return/throw protocol (return value is ignored). It'd be much
more explicit this way.
Agreed.
I would be fine with that, although it might be a bit inconsistent
with other traps like "set", "defineProperty", etc. which all return
booleans to indicate success.
There is a precedent for defineProperty because [[DefineOwnProperty]]
returns a boolean. After-refactor-[[Set]] also returns a boolean, so it
makes sense the set operation does too.
That said, this trap is already the odd one out: it doesn't really
make sense to define a Reflect.unknownPrivateSymbol method either,
like we did for all other traps.
IOW, unknownPrivateSymbol is really more like a notification callback
than a real trap that gets to return some useful value.
I agree with this view.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
