Proposal: Abstract References

Andreas Rossberg rossberg at
Thu Oct 30 01:32:40 PDT 2014

On 29 October 2014 21:59, Mark S. Miller <erights at> wrote:
> On Wed, Oct 29, 2014 at 8:16 AM, Andreas Rossberg <rossberg at>
> wrote:
>> On 27 October 2014 16:50, Tom Van Cutsem < at> wrote:
>> > 2014-10-27 15:00 GMT+01:00 Andreas Rossberg <rossberg at>:
>> >>
>> >> > 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

As I said, this would really be the exact same model as we already
have for built-in / host internal state.


More information about the es-discuss mailing list