d at domenic.me (2014-11-18T22:35:35.164Z)
On 29 October 2014 21:59, Mark S. Miller <erights at google.com> wrote: > Yes. We're talking about class-private instance state, not instance-private > instance state, so one instance can be asked about another alleged instance. Yes, that's what I am talking about as well. Maybe I'm being dense, but again, where does class-private instance state require a private name / weak map to go _through_ a membrane? Any legal instance would always originate from the same side, i.e., would be unproxied when encountered by a method. So accessing the private state works where it should work. Symmetrically, as long as proxies simply signal absence of private fields (without leaking private symbols to any trap), it also works correctly (i.e., fails) to ask a non-instance about private fields. As I said, this would really be the exact same model as we already have for built-in / host internal state.
On 29 October 2014 21:59, Mark S. Miller <erights at google.com> wrote: > On Wed, Oct 29, 2014 at 8:16 AM, Andreas Rossberg <rossberg at google.com> > wrote: >> >> On 27 October 2014 16:50, Tom Van Cutsem <tomvc.be at gmail.com> wrote: >> > 2014-10-27 15:00 GMT+01:00 Andreas Rossberg <rossberg at google.com>: >> >> >> >> > but without breaking membrane transparency. >> >> >> >> I'm still not sure I understand how this affects membranes >> >> specifically. A membrane would never pass a proxied object to a >> >> non-proxied function from the same side. So functions accessing (or >> >> testing for) private state on an object are a non-issue in that >> >> scenario, because this access never crosses the membrane, does it? >> >> After all, membranes work just fine with builtins or host objects >> >> (otherwise they would be useless). >> > >> > I believe what Mark was referring to is the fact that if a WeakMap >> > crosses >> > the membrane, it gets proxied. Manipulating the WeakMap using >> > WeakMap.prototype.{get,set} subsequently allows the membrane to >> > intercept >> > and wrap those operations. >> >> Sure, I understand. However, my point was that in the usual private >> state scenario, the weak map / private symbol _itself_ would never >> actually cross the membrane. All its uses are encapsulated on one >> side. So at least ordinary private state via private properties (e.g. >> as part of a class abstraction) is not actually an issue for >> membranes. Or am I missing something? > > Yes. We're talking about class-private instance state, not instance-private > instance state, so one instance can be asked about another alleged instance. Yes, that's what I am talking about as well. Maybe I'm being dense, but again, where does class-private instance state require a private name / weak map to go _through_ a membrane? Any legal instance would always originate from the same side, i.e., would be unproxied when encountered by a method. So accessing the private state works where it should work. Symmetrically, as long as proxies simply signal absence of private fields (without leaking private symbols to any trap), it also works correctly (i.e., fails) to ask a non-instance about private fields. As I said, this would really be the exact same model as we already have for built-in / host internal state. /Andreas