On notification proxies

David Bruant bruant.d at gmail.com
Tue Mar 5 10:03:26 PST 2013

Le 05/02/2013 16:29, David Bruant a écrit :
> Le 05/02/2013 13:52, Sam Tobin-Hochstadt a écrit :
>> Second, it forces
>> the use of the "shadow target" pattern in any wrapper, doubling the
>> number of allocations required.
> I don't understand why more shadow targets would be necessary than 
> with direct proxies.
Sorry for the very late understanding, but I finally get it.
In the case of a membrane, the object used as target needs to have the 
wrapped objects as property values, which means one of the following:
1) change the actual target in the pre-trap and change it back in the 
post trap. This back and forth has to be done at every property access.
2) shadow target

Hmm... actually, because of constraints of the getPrototypeOf trap, 
membranes implementation has to (lazily) duplicate the entire graph of 
reachable objects.

In cases where it'd be acceptable to share prototypes (because they'd be 
frozen and hold no powerful reference, for instance), one can wonder if 
1) is that cheaper than the invariants notification proxies are meant to 
remove (add+remove prop and enter/exit 2 function calls)


More information about the es-discuss mailing list