Membranes, unmediated access to objects through Object.getPrototypeOf

David Bruant bruant.d at gmail.com
Wed Oct 10 01:51:25 PDT 2012


2012/10/10 David Bruant <bruant.d at gmail.com>

> About making the restriction for membranes "official" could be done by
> introducing "branded proxies" which output values (through
> get/getOwnPropertyDescriptor/getPrototypeOf... traps) would also be
> "branded proxies" (with the same brand). Brand validation would be
> performed to ensure graph isomorphism. It ensures that you deviate from the
> exact target, but only with a given proxy and only because you're coming
> from a branded proxy (and not for no reason).
>
>
I have given more thoughts to this idea.

Proxy.branded(brand, target, handler) // brand is a symbol

The trap invariants would not rely on SameValue for object equality
anymore, but if an object is returned from a trap, it has to be *the
unique* proxy created of off the (brand, target) pair instead of what
happens currently where it has to be the target (which is the unique object
which identity is equal to the target's identity). The invariant can be
implemented with a weakmap of weaksets and each test is at worst 2 lookups
(one on the weakmap, the other on the weakset), so
O(log(NumberOfTargets*NumberOfBrands)). Arguably heavy-weight, but I don't
think it can be made better.

Having this uniqueness invariant is what enforces graph isomorphism. In a
nutshell, unlike the current proposal, traps can still return proxies, but
it has to be the exact proxy that can be returned is decided in advanced,
pretty much like the current invariants where there is no choice on the
object to be returned. What I'm proposing, just shifts which the set of
objects from the targets set to a particular set of proxies.

Proxy.branded.bind(someBrand) would create a new Proxy constructor somehow
specialized to create a membrane.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121010/6efdb6c5/attachment-0001.html>


More information about the es-discuss mailing list