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
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
Le 21/01/2013 22:31, Tom Van Cutsem a écrit :
Let's talk through Allen and Brandon's suggestion of auto-unwrapping
private symbol access on proxies.
If a membrane can intercept all exchanged private symbols I think this
could be made to work.
Agreed. Unfortunately, I think the condition (If a
2013/1/22 David Bruant bruan...@gmail.com
Le 21/01/2013 22:31, Tom Van Cutsem a écrit :
Let's talk through Allen and Brandon's suggestion of auto-unwrapping
private symbol access on proxies.
If a membrane can intercept all exchanged private symbols I think this
could be made to work.
Le 22/01/2013 16:02, Tom Van Cutsem a écrit :
2013/1/22 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 21/01/2013 22:31, Tom Van Cutsem a écrit :
Let's talk through Allen and Brandon's suggestion of
auto-unwrapping private symbol access on proxies.
If
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
Le 21/01/2013 03:35, Allen Wirfs-Brock a écrit :
On Jan 20, 2013, at 5:42 PM, David Bruant wrote:
Le 20/01/2013 23:05, Allen Wirfs-Brock a écrit :
On Jan 20, 2013, at 11:12 AM, David Bruant wrote:
complicated was an expression. Either proxies don't work with
class instances, making them
2013/1/20 Kevin Smith khs4...@gmail.com
It is not. At the exit of the get trap, the JS engine checks whether
invariants should be enforced for the given property on the target. In your
case, the runtime sees that the target has a non-configurable non-writable
property called 'foo' with 1 as
2013/1/20 Allen Wirfs-Brock al...@wirfs-brock.com
I don't have a problem at all with making the proxy story more
complicated. Proxys are an expert feature designed for some specific use
cases. they are probably an attractive nuisance. I would advise most JS
programmer that if they are
2013/1/21 Brandon Benvie bran...@brandonbenvie.com
On Sun, Jan 20, 2013 at 10:41 PM, Brendan Eich bren...@mozilla.comwrote:
Brandon Benvie wrote:
Going to the title of this thread, it's my view that private symbols
should just auto-forward to the ultimate target no matter what,
Doesn't
Amen.
/Andreas
On 21 Jan 2013 17:23, Tom Van Cutsem tomvc...@gmail.com wrote:
2013/1/20 Allen Wirfs-Brock al...@wirfs-brock.com
I don't have a problem at all with making the proxy story more
complicated. Proxys are an expert feature designed for some specific use
cases. they are probably
A root problem is that on method invocations through a proxy methods of
the target object are invoked with the proxy, rather than the target, as
the this value. This means that any assumption the methods have about
valid this values are broken.
I believe this is correct. It is a separate
On Jan 21, 2013, at 4:44 PM, Nathan Wall wrote:
Object.create(new Date).getDate(); // works but is specified to not work
I understand why this doesn't work, but why *shouldn't* it work? I'm curious
why the language doesn't allow for this... ? It seems reasonable at first
glance.
Le 20/01/2013 06:36, Kevin Smith a écrit :
It is not. At the exit of the get trap, the JS engine checks
whether invariants should be enforced for the given property on
the target. In your case, the runtime sees that the target has a
non-configurable non-writable property called
Got it. And one more (thanks for bearing with me): what affect does
throwing an error have within a trap?
var target = {
foo: function() { this.bar; console.log(after bar); },
bar: 0
};
var proxy = new Proxy(target, {
get: function(obj, name) {
if (name
David Bruant wrote:
I disagree with Brendan when he says to use weakmaps for class
private instance methods/variables... well... it depends on what
use means:
The spec is allowed to /use/ anything it needs to make the class
private syntax work. If the spec says that private properties are like
David Bruant wrote:
Once again, the spec (well... you in that case :-) ) will do whatever
is necessary to make the feature understandable by spec readers.
Transpilers will work with whatever is in the language. If they only
have weakmaps, they'll use that.
See
Le 20/01/2013 18:59, Brendan Eich a écrit :
David Bruant wrote:
I disagree with Brendan when he says to use weakmaps for class
private instance methods/variables... well... it depends on what
use means:
The spec is allowed to /use/ anything it needs to make the class
private syntax work. If
Le 20/01/2013 18:54, Allen Wirfs-Brock a écrit :
On Jan 20, 2013, at 3:04 AM, David Bruant wrote:
Le 20/01/2013 05:27, Allen Wirfs-Brock a écrit :
Weakmaps and symbol keyed properties (private or not) are very different
mechanism. They each have a variety of uses and differing
Le 20/01/2013 19:01, Brendan Eich a écrit :
David Bruant wrote:
Once again, the spec (well... you in that case :-) ) will do whatever
is necessary to make the feature understandable by spec readers.
Transpilers will work with whatever is in the language. If they only
have weakmaps, they'll use
Allen Wirfs-Brock wrote:
We we were going to talk about adding support for addition semantics to
classes we should start at the level of the object model. Not with syntax. ES6
class syntax is good because it is defined in terms of the object model and
more basic operations that are defined
On Jan 20, 2013, at 11:12 AM, David Bruant wrote:
Le 20/01/2013 18:54, Allen Wirfs-Brock a écrit :
On Jan 20, 2013, at 3:04 AM, David Bruant wrote:
Le 20/01/2013 05:27, Allen Wirfs-Brock a écrit :
Weakmaps and symbol keyed properties (private or not) are very different
mechanism. They
Skipping contentious stuff (some of which, e.g. classes as sugar, I
agree with -- and so does TC39) to get to this paragraph:
Allen Wirfs-Brock wrote:
The [[Get]] and [[Set]] (and probably some others) internal methods of a proxy never
call the corresponding trap when the property key is a
On Jan 20, 2013, at 2:27 PM, Brendan Eich wrote:
Skipping contentious stuff (some of which, e.g. classes as sugar, I agree
with -- and so does TC39) to get to this paragraph:
Allen Wirfs-Brock wrote:
The [[Get]] and [[Set]] (and probably some others) internal methods of a
proxy never
Err I take it back. They can be implemented in terms of private symbols,
but every access has to be guarded with a hasOwn check which would be
observable to a Proxy.
On Sunday, January 20, 2013, Brandon Benvie wrote:
On Sunday, January 20, 2013, Allen Wirfs-Brock wrote:
I'm not sure if you
Allen Wirfs-Brock wrote:
Perhaps you're in favor of that in addition? But if so, how would one proxy
such that the @@DateValue symbol was the name parameter to get and set traps?
I'm not sure if you are getting at something other than what I've described
above. If a @@DateValue private
On Jan 20, 2013, at 4:42 PM, Brandon Benvie wrote:
On Sunday, January 20, 2013, Allen Wirfs-Brock wrote:
I'm not sure if you are getting at something other than what I've described
above. If a @@DateValue private symbol is actually used as the
implementation of [[DateValue]] then
On Jan 20, 2013, at 4:46 PM, Brandon Benvie wrote:
Err I take it back. They can be implemented in terms of private symbols,
but every access has to be guarded with a hasOwn check which would be
observable to a Proxy.
Well, proxy observability is the topic of discussion. they wouldn't be
On Jan 20, 2013, at 5:42 PM, David Bruant wrote:
Le 20/01/2013 23:05, Allen Wirfs-Brock a écrit :
On Jan 20, 2013, at 11:12 AM, David Bruant wrote:
complicated was an expression. Either proxies don't work with class
instances, making them vastly pointless or classes need to publicize
This looks to address the issues. The reason Proxoes would work (it doesn't
currently because I opted to switch back to using a regular internal
property because of the issue I mentioned) is because getting the date
value changes from get internal property value for which Proxies have no
specified
On Sun, Jan 20, 2013 at 10:41 PM, Brendan Eich bren...@mozilla.com wrote:
Brandon Benvie wrote:
Going to the title of this thread, it's my view that private symbols
should just auto-forward to the ultimate target no matter what,
Doesn't this allow private symbols to pierce membranes? Or do
Er to clarify, I didn't mean non-proxied. I meant directly forwarded to the
target with no possibility of a malfunction or interception by any proxy
traps. I want the property forwarded unconditionally, so it has the same
guarantees that a regular [[Get]] does (except in the case of revokable
The interaction between private syntax and proxies has the following
components:
1) Do the proxy and the target act the same regarding private properties?
The answer is yes with whitelisted private symbols, no with naive
weakmap-expanded private syntax (I explain non-naive below)
What
Le 19/01/2013 16:30, Kevin Smith a écrit :
The interaction between private syntax and proxies has the
following components:
1) Do the proxy and the target act the same regarding private
properties?
The answer is yes with whitelisted private symbols, no with naive
It calls the unknownPrivateSymbol trap. If the trap throws, the operation
fails. In all other cases (no trap or trap which doesn't throw), it's
forwarded.
And can frozen objects be proxy targets, or no? More generally, can a
proxy effectively override the behavior of a non-configurable,
Le 19/01/2013 19:04, Kevin Smith a écrit :
It calls the unknownPrivateSymbol trap. If the trap throws, the
operation fails. In all other cases (no trap or trap which doesn't
throw), it's forwarded.
And can frozen objects be proxy targets, or no?
Yes they can.
More generally,
Something was nagging me from the 2011-era debate over private symbols
vs. weak maps, and that's the ability of a weak map to implement soft
fields on frozen objects. Symbols (private or not) can't do that.
Not sure this matters in the current proxy-focused thread, but I thought
I would point
On Jan 19, 2013, at 11:39 AM, Brendan Eich wrote:
Something was nagging me from the 2011-era debate over private symbols vs.
weak maps, and that's the ability of a weak map to implement soft fields on
frozen objects. Symbols (private or not) can't do that.
Not sure this matters in the
Allen Wirfs-Brock wrote:
Who's to say that a symbol keyed object
You must mean property not object.
can't be added to an object after Object.freeze has been applied to it. Before we can
say that we have to define the semantics of symbol keyed objects and possibly extend
Allen Wirfs-Brock wrote:
On Jan 19, 2013, at 6:02 PM, Brendan Eich wrote:
Frozen objects could even be promoted by a copying GC into read-only memory,
with the OS virtualized hardware MMU providing greater integrity.
But here you are talking about some broader from of immutability that
It is not. At the exit of the get trap, the JS engine checks whether
invariants should be enforced for the given property on the target. In your
case, the runtime sees that the target has a non-configurable non-writable
property called 'foo' with 1 as value. When you try to return 0, it will
On Jan 19, 2013, at 8:39 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
...
I like the fact that you used r as a name above because certainly a
WeakMap can be used to define a relationship involving an immutable object
o. But we shouldn't be creating confusion by pretending that
:* Thursday, January 17, 2013 21:40
*To:* Mark S. Miller
*Cc:* Brendan Eich; es-discuss
*Subject:* Re: Security Demands Simplicity (was: Private Slots)
It seems as if this approach to private class members also allows us
to describe private methods in a convenient way. Private methods can
*Subject:* Re: Security Demands Simplicity (was: Private Slots)
It seems as if this approach to private class members also allows us to
describe private methods in a convenient way. Private methods can be
attached to the _prototype_ of the private field object, thus avoiding
per-instance allocation
Le 18/01/2013 06:47, Russell Leggett a écrit :
On Thu, Jan 17, 2013 at 9:40 PM, Kevin Smith khs4...@gmail.com
mailto:khs4...@gmail.com wrote:
It seems as if this approach to private class members also allows
us to describe private methods in a convenient way. Private
methods can
Kevin, could you do an alterna-gist as Domenic proposes? Of course there's
much more at stake than syntax, but it would help.
I've updated my gist to clarify Domenic's second point, but I'll let him
maintain his fork for the @ syntax variation.
{ Kevin }
I've been stewing on this some more, and I realized something potentially
very interesting. If we use weakmaps in the manner specified by Kevin (with
Mark's help),
Um, that should be Mark (with Kevin's itty-bitty help). : )
{ Kevin }
___
es-discuss
First, I agree with David that security is important, both for
security per se and for modularity in general. ES5 improved the
language when it fixed the accidental leaks between the world of
objects and scope-chain objects, like thrown functions. ES5/strict
improved the language when it made
On 17 January 2013 18:00, Mark S. Miller erig...@google.com wrote:
I still have this position on classes. But I no longer buy that
pessimistic conclusion about WeakMaps. Consider how WeakMaps would be
used by the expansion of classes-with-private. Just 'cause it's on the
top of my head, below
On Thu, Jan 17, 2013 at 9:13 AM, Andreas Rossberg rossb...@google.com wrote:
Hm, I'm afraid I don't fully understand that example. There seems to
be a missing closing brace for the constructor, and I don't know what
the free occurrences of 'balance' are referring to. Also, the second
line of
Still not right. I screwed up the scoping of the balance variable.
Another correction coming soon.
On Thu, Jan 17, 2013 at 9:17 AM, Mark S. Miller erig...@google.com wrote:
On Thu, Jan 17, 2013 at 9:13 AM, Andreas Rossberg rossb...@google.com wrote:
Hm, I'm afraid I don't fully understand that
(As usual, trying to write code in a hurry actually cost more time :(.
Sorry to have spent every else's time as well :(. )
class Purse {
constructor(private balance) {}
getBalance() { return balance; }
makePurse() { return new Purse(0); }
deposit(amount, srcPurse) {
Mark S. Miller wrote:
I also agree with David that unique symbols are not an encapsulation
mechanism, but rather, merely a mechanism to avoid namespace
collisions.
However, after the Private Slots thread, I spent a sleepless night
chewing on getting rid of private symbols. I now think we
Le 17/01/2013 18:00, Mark S. Miller a écrit :
However, after the Private Slots thread, I spent a sleepless night
chewing on getting rid of private symbols.
Happens to me so often :-)
I now think we should.
Going back to my earlier
On Wed, Jan 16, 2013 at 12:37 PM, Mark S. Miller
On Thu, Jan 17, 2013 at 10:02 AM, David Bruant bruan...@gmail.com wrote:
Le 17/01/2013 18:00, Mark S. Miller a écrit :
However, after the Private Slots thread, I spent a sleepless night
chewing on getting rid of private symbols.
Happens to me so often :-)
I now think we should.
Going
I just looked back at the example code in Distributed Electronic Rights in
JavaScript. It uses WeakMaps in two places: Fig1 line2 and Fig3 line2.
Both of these express objects using the objects-as-closures pattern, not
using classes. It's clearly affordable here since there are only 3 and 2
Le 17/01/2013 19:30, Mark S. Miller a écrit :
On Thu, Jan 17, 2013 at 10:02 AM, David Bruant bruan...@gmail.com wrote:
Le 17/01/2013 18:00, Mark S. Miller a écrit :
I still have this position on classes. But I no longer buy that
pessimistic conclusion about WeakMaps. Consider how WeakMaps
The Ephemeron gc technique
contributes nothing to the ability to reclaim space for such code
because of the relative lifetimes of the map and its keys.
Yes - my line-of-thought as well. If I may riff on your code a bit (ymmv):
class Purse {
// Move private field declaration
On Thu, Jan 17, 2013 at 1:13 PM, David Bruant bruan...@gmail.com wrote:
Le 17/01/2013 19:30, Mark S. Miller a écrit :
2) Until ES7 provides private
I may have missed something. In the harmony proposal on the wiki [1] (is the
wiki down? I'm looking at google's cache),
I don't know, but seems
November's meeting had re-instituted computed property names to compensate
for the dropping @name support to allow for symbols to be used as method
names. AFAICT there's currently no actual way to create a private Symbol in
any active proposals for ES6, however (this was only covered as part of
On Thu, Jan 17, 2013 at 1:50 PM, Mark S. Miller erig...@google.com wrote:
On Thu, Jan 17, 2013 at 1:13 PM, David Bruant bruan...@gmail.com wrote:
Le 17/01/2013 19:30, Mark S. Miller a écrit :
2) Until ES7 provides private
I may have missed something. In the harmony proposal on the wiki [1]
It seems as if this approach to private class members also allows us to
describe private methods in a convenient way. Private methods can be
attached to the _prototype_ of the private field object, thus avoiding
per-instance allocation. Of course, the correct this value has to be
used in the
On Thu, Jan 17, 2013 at 9:40 PM, Kevin Smith khs4...@gmail.com wrote:
It seems as if this approach to private class members also allows us to
describe private methods in a convenient way. Private methods can be
attached to the _prototype_ of the private field object, thus avoiding
the following fork: https://gist.github.com/4562796
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Kevin Smith
Sent: Thursday, January 17, 2013 21:40
To: Mark S. Miller
Cc: Brendan Eich; es-discuss
Subject: Re: Security Demands Simplicity (was: Private Slots
91 matches
Mail list logo
