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.




>
> I'm not sure what the scenarios would be where a private symbol itself
> would be desired to pass a membrane in a first class manner. It seems
> like in all such scenarios, ordinary weak maps or other means can be
> used -- while still allowing more efficient private properties in the
> others.
>
> > With (private) symbols, we couldn't come up with a satisfactory way to
> > combine them with membranes. Treating the symbol as data and passing it
> > straight through the membrane creates an obvious leak. Treating it as an
> > opaque identity and proxying that identity results in a useless proxied
> > identity on the other side of the membrane. W.r.t. membranes, the key
> point
> > of using WeakMaps for private state is that the membrane can properly
> > intercept the 'get' and 'set' operations.
>
> To avoid leaks, private symbols could be treated essentially like
> internal [[_]] properties. That is, they are simply deemed absent on a
> proxy, no matter what the target. Get/Has unconditionally return
> undefined/false, Set/Define unconditionally reject. AFAICS, that does
> not affect membranes handling objects with private properties
> correctly, see above.
>
> Clearly, it's not a perfect solution. One question would remain: what
> to do about passing a private symbol _itself_ through a membrane, in a
> first-class manner? One idea: the membrane could map private symbols
> to public symbols, and make sure that all object proxies it creates
> treat the set of these symbols _as if_ they were private, i.e., filter
> them in reflection traps (after all, reflection on object properties
> is the only place where public and private symbols really differ). The
> only case that would not work is when the private symbols from _one_
> side of the membrane are supposed to be used to create private
> properties on objects from the _other_ side. But is that a real
> scenario? That can't be dealt with pragmatically by just using weak
> maps in that case?
>
> /Andreas
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141029/102d0b63/attachment.html>

On Wed, Oct 29, 2014 at 8:16 AM, Andreas Rossberg <rossberg at google.com> wrote:

> 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.