Action proxies

[Tom Van Cutsem]

Hi David,

In short, I don't think action proxies bring anything more to the table
than notification proxies and are not worth pursuing separately. Replies to
more detailed points below:

2013/2/3 David Bruant <bruant.d at gmail.com>

> Le 03/02/2013 01:59, Mark S. Miller a écrit :
>
>  Hi David, have you seen https://github.com/tvcutsem/**
>> harmony-reflect/tree/master/**notification<https://github.com/tvcutsem/harmony-reflect/tree/master/notification>?
>>
> I remember seeing the announcement, but I must have forgotten about it. My
> bad :-s
>
>
>  AFAICT, this provides the same flexibility as action proxies with hardly
>> any more mechanism and overhead than bare notification proxies. The key is
>> that, if the pre trap returns a callable, the proxy calls that callable
>> after the action as a post trap. No need to reify an action thunk, ever,
>> though in exchange the pre trap must often allocate the post trap it
>> returns.
>>
> Either allocate or keep the post-trap around for reuse, but yes.
> On the post trap of getOwnPropertyDescriptor and keys, I would pass an
> iterator as argument, because it is not sure the post-trap will actually
> look at the result, so no absolute need to re-allocate the array. Or maybe
> wrap the array in a (built-in) readonly proxy (throws on writing traps).
>

I think these are implementation-level optimizations that shouldn't
necessarily be exposed in the API.

Also, the above API is not yet up-to-date w.r.t. the latest agreement on
how to deal with traps that return multiple property names. Allen has
specced an "ownKeys" trap that would return an iterator. The
getOwnPropertyNames trap, on the other hand, can continue to return an
array since Object.getOwnPropertyNames must still return an array anyway.


> Speaking of iterator, if the enumerate pretrap returns an iterator with an
> editable "next" method, can the post-trap modify the next method? Maybe
> there is some necessary wrapping in that case too.


The enumerate pre-trap cannot return an iterator (its return value is
ignored). Presumably you meant to say: if the result of forwarding
enumerate() is an iterator, and we pass that iterator to the post-trap, can
the post-trap mess around with the iterator? The answer is yes: the
post-trap could e.g. fully exhaust the iterator, such that the proxy's
client actually sees 0 keys. I think this is fine for property enumeration.
getOwnPropertyNames would be the reliable way to query an object for its
own property names.


>
>  Is there any remaining advantage of action proxies over this?
>>
> Trap names don't start with "on"? :-) I don't think the "on" is absolutely
> necessary, but that's more of a style issue.


I think the "on"-prefix is actually pretty important. It signals to the
proxy writer that the trap is a callback whose return value will be ignored.


> Otherwise, I don't think so. Unless I'm overlooking something, I think
> there is the following equivalence:
>
>     // action proxy:
>     trap: function(){
>         // pre-trap code
>         action();
>         // post-trap code
>     }
>
>     // notification proxy:
>     trap: function(){
>         // pre-trap code
>         return () =>{
>             // post-trap code
>         }
>     }
>
>
Correct. Note that if no post-trap is needed, there is no allocation
overhead in the case of notification proxies. That's a net win compared to
action proxies. Action proxies would require sophisticated optimizations to
obtain the same benefits. It's better not to count on that.


> The post-trap code is optional in the former part equivalently to the
> return statement in the latter.
>
> This does indeed get rid of invariant checks while guaranteeing the
> invariants anyway and apparently not losing expressiveness. Wow.
>
> Was this discussed during the January TC39 meeting? Do notification
> proxies have a chance to replace direct proxies or is it too late?
> In the case it would be too late, could "throw ForwardToTarget" be
> considered?


I wasn't present but I think notification proxies were discussed briefly.
We need to work on an implementation of membranes for notification proxies
to see if they can fully supplant proxies.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130203/a371b1ff/attachment.html>