2013/1/28 Tom Van Cutsem tomvc...@gmail.com
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
The page actually lists two proposals, out of
2013/1/29 Brandon Benvie bran...@brandonbenvie.com
I realized the discrepancy between my thinking and what you said. In the
case of a membrane, you are correct. A membrane will always unwrap
everything, so you will only ever end up with dry method/dry this. That
makes all the different forms
I would then suggest, as awb has, the creation of CallProperty (or Invoke)
which fixes the problem in most circumstances. With the existence of
WeakMaps and private symbols, the dry method/wet this problem is going to
be an extremely common one.
On Tue, Jan 29, 2013 at 3:19 AM, Tom Van Cutsem
On Mon, Jan 28, 2013 at 11:27 PM, Brandon Benvie
bran...@brandonbenvie.comwrote:
I realized the discrepancy between my thinking and what you said. In the
case of a membrane, you are correct. A membrane will always unwrap
everything, so you will only ever end up with dry method/dry this. That
To elaborate, I've realized that my main disagreement with your position
(really my care at all with the private discussion) is much better solved
by introducing [[CallProperty]]. That is: Proxies currently handle |this|
binding of method calls very poorly. I'm all for either removing private or
Brandon Benvie wrote:
To elaborate, I've realized that my main disagreement with your position
(really my care at all with the private discussion) is much better
solved by introducing [[CallProperty]]. That is: Proxies currently
... and complicates object model. My main problem with
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
The page actually lists two proposals, out of which I prefer the second one.
If I forgot some
Hi Tom, as you and I discussed in chat, (base case) there are no built-in
private symbols in a standard JS environment (i.e. all the built-in symbols
are unique) is a bad misunderstanding of the utility of membranes.
Membranes (and membrane-like patterns) are useful and needed at many
finer-grains
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
On 28 January 2013 19:45, Tom Van Cutsem tomvc...@gmail.com wrote:
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
The page actually lists
On Mon, Jan 28, 2013 at 11:52 AM, Andreas Rossberg rossb...@google.comwrote:
On 28 January 2013 19:45, Tom Van Cutsem tomvc...@gmail.com wrote:
I just wrote up a strawman on the wiki to summarize the recent debates
about
the interaction between proxies and private symbols:
Tor this[symbol] = value or equivalent on one side of a membrane, followed
by this[symbol] or equivalent on the other side of the membrane, we have
the following eight cases.
For all of these, o1 is the original non-proxy thing associated with the
private properties.
p1 is the proxy result of
The assumption that my conclusion on auto-unwrapping rests on is that the
situation shouldn't arise where a wet value is set as a dry object's
private property. The reasoning is that the private key is presumed to be
something closely guarded and that won't be shared in such a way that this
So the corresponding WeakMap situation would be one where the WeakMap o2 is
never passed through the membrane, so there is no p2 on the other side of
the membrane. In that scenario, AFAICT PrivateSymbol proposal #1, #2, and
WeakMaps are all equivalent. Not so?
On Mon, Jan 28, 2013 at 4:19 PM,
On Mon, Jan 28, 2013 at 3:59 PM, Mark Miller erig...@gmail.com wrote:
Tor this[symbol] = value or equivalent on one side of a membrane, followed
by this[symbol] or equivalent on the other side of the membrane, we have
the following eight cases.
That should be For thing[symbol] = value or
I realized the discrepancy between my thinking and what you said. In the
case of a membrane, you are correct. A membrane will always unwrap
everything, so you will only ever end up with dry method/dry this. That
makes all the different forms of private equivalent. The difference arises
when you're
2013/1/28 Mark S. Miller erig...@google.com
Hi Tom, as you and I discussed in chat, (base case) there are no
built-in private symbols in a standard JS environment (i.e. all the
built-in symbols are unique) is a bad misunderstanding of the utility of
membranes. Membranes (and membrane-like
Le 24/01/2013 09:52, Tom Van Cutsem a écrit :
2013/1/23 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 23/01/2013 09:38, Tom Van Cutsem a écrit :
3) because of JS's invoke = get + apply semantics, by
default a proxy always leaves the |this| value pointing at
Le 22/01/2013 21:09, David Bruant a écrit :
Le 22/01/2013 20:05, Tom Van Cutsem a écrit :
Symbol-keyed indexing on the A face is distinct from symbol-keyed
indexing on the B face. But that's OK: it's the job of the membrane
to separate the A and the B face in the first place.
I don't think
Just to clarify, the example I gave of WeakMap usage breaking with proxies
was just to illustrate how a type of private data currently in use
alongside proxies can break the target object purely by accident. While I
do think [[CallMethod]] would go a long way to ameliorating the problem, I
still
2013/1/23 Brendan Eich bren...@mozilla.com
Brandon Benvie wrote:
It is my opinion that the primary use case for private symbols is for
properties that proxies expressly shouldn't be given a chance, in any
manner, to corrupt or modify. They are likely used for sensitive internal
state that
2013/1/23 Tom Van Cutsem tomvc...@gmail.com
Looking back at the code for an identity-preserving membrane
http://wiki.ecmascript.org/doku.php?id=harmony:proxies#an_identity-preserving_membrane
I think this membrane actually properly unwraps the |this| value before
forwarding.
The relevant
Tom Van Cutsem wrote:
2013/1/23 Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com
Brandon Benvie wrote:
It is my opinion that the primary use case for private symbols
is for properties that proxies expressly shouldn't be given a
chance, in any manner, to
Le 23/01/2013 09:38, Tom Van Cutsem a écrit :
3) because of JS's invoke = get + apply semantics, by default a
proxy always leaves the |this| value pointing at the proxy.
Looking only at 3), sometimes this is what you want, and sometimes it
isn't.
In which case would it be what you want?
The
2013/1/22 Allen Wirfs-Brock al...@wirfs-brock.com
We can probably fix the built-ins with some ad hoc language about them
automatically resolving proxies to the target as the this value. Or perhaps
we could expand the internal MOP api to include a resolve proxy to target
operation.
Using
Kevin Smith pointed out something I hadn't though about before but is
obvious in retrospect. The hazard that proxies bring to the language in
general: proxies make it possible to break the target object by
inconsistently handling forwarding during the operation of methods.
class Counter {
On Jan 22, 2013, at 9:06 AM, Brandon Benvie wrote:
Kevin Smith pointed out something I hadn't though about before but is obvious
in retrospect. The hazard that proxies bring to the language in general:
proxies make it possible to break the target object by inconsistently
handling
Le 22/01/2013 16:13, Tom Van Cutsem a écrit :
2013/1/22 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
We can probably fix the built-ins with some ad hoc language about
them automatically resolving proxies to the target as the this
value. Or perhaps we could
2013/1/22 David Bruant bruan...@gmail.com
Just realizing now, but how does the membrane do the symbol unwrapping
if private symbols pierces it?
2 contexts A and B share a symbol, the symbol initially has to go through
a public channel (get trap with a string name for instance) and if A
Le 22/01/2013 20:05, Tom Van Cutsem a écrit :
2013/1/22 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Just realizing now, but how does the membrane do the symbol
unwrapping if private symbols pierces it?
2 contexts A and B share a symbol, the symbol initially has to go
Brandon Benvie wrote:
It is my opinion that the primary use case for private symbols is for
properties that proxies expressly shouldn't be given a chance, in any
manner, to corrupt or modify. They are likely used for sensitive
internal state that will only be accessed by methods or friend
31 matches
Mail list logo
