July 26, 2012 TC39 Meeting Notes
Tom Van Cutsem
tomvc.be at gmail.com
Thu Aug 2 11:34:18 PDT 2012
2012/8/2 David Bruant <bruant.d at gmail.com>
> 2012/8/2 Tom Van Cutsem <tomvc.be at gmail.com>
> We should also reconsider the simplest alternative of just not trapping
>> private names on proxies.
> You mentionned that if private names aren't trapped, it pierces membranes,
> so when you want to prevent access to objects in the membrane, you can't
> for private names.
> A softer option in the direction of "not trapping" would be to have a
> privateNameSink for known and unknown names. It leaves the opportunity to
> not pierce membranes (but I don't know if it's detrimental to other use
Private names would pierce membranes only if they would auto-unwrap the
proxy and forward to the target by default. There is another
option: attempts to get/set values via a private name on a proxy could just
behave as they would on a non-proxy object (i.e. a proxy would have its own
storage for private name properties).
This option is consistent with at least two other design choices we've made:
- WeakMaps don't interact with proxies either. You can associate private
state with a proxy via a WeakMap without the proxy being able to trap this.
- From our discussion last week, I recall that Object.observe won't be able
to observe updates to privately named properties.
Another way of looking at things is that private names combine the
receiver's object identity with the private name's identity to produce a
value. Since proxies have their own object identity, it follows that keying
off of a proxy results in a different value than keying off of any other
Membranes would resist private name access by default, unless a membrane
proxy explicitly copies its target's privately-named-properties onto itself
[one caveat being that it won't be able to keep the copies in-sync, as
Object.observe won't reflect updates to these properties].
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss