On notification proxies
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
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