2012/8/2 David Bruant <[email protected]> > 2012/8/2 Tom Van Cutsem <[email protected]> > > 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 > cases) >
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 object. 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]. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
