Ok, thanks for your clarifying example.
I see your point. Basically you want obj[privateSymbol] to be a
high-integrity operation that proxies cannot even abort (unless they know
about the private symbol). That would give
private-symbol-keyed-property-access a special status, since other
important
2013/1/10 Brendan Eich bren...@mozilla.com
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
Le 15/01/2013 20:32, Tom Van Cutsem a écrit :
2013/1/10 Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com
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
2013/1/15 David Bruant bruan...@gmail.com
Le 15/01/2013 20:32, Tom Van Cutsem a écrit :
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
Tom Van Cutsem wrote:
2013/1/15 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 15/01/2013 20:32, Tom Van Cutsem a écrit :
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
These use cases can be made dynamic be some kind of
Proxy.fromNowOnForwardUnknownPrivateSymbols(proxy, false);
API. This is not truly dynamic. I'd say no truly dynamic use cases
exist, where you must decide _at_the_exact_point_of_access_. IMO.
I would be ok with something more along the
set(key, value) {
let data = this[$data];
if (!data)
throw new TypeError('this object must be a StringMap');
if (!(key in data))
this[$size]++;
data[key] = value;
}
Doh! I wrote that in such a way that an inconsistency cannot be introduced,
since
[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.
On Thu, Jan 10, 2013 at 1:24 PM, David Bruant bruan...@gmail.com wrote:
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.
FWIW, I kinda like the aesthetics of return/throw a bit better too,
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.
Le 10/01/2013 22:31, Tab Atkins Jr. a écrit :
On Thu, Jan 10, 2013 at 1:24 PM, David Bruant bruan...@gmail.com wrote:
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.
FWIW, I kinda like the
11 matches
Mail list logo
