Action proxies

[David Bruant]

Le 04/02/2013 18:51, Brendan Eich a écrit :
> If notification proxies require allocation per trap activation, that's 
> a fatal flaw in my view.
I assume you mean allocation of trap return values and will discuss 
that, if you mean something else, please expand.

Before stating anything, let's compare notification proxies with direct 
proxies.

# No post-trap case:
     // direct proxies
     trap(...args){
         // pretrap code
         return Reflect.trap(...args)
     }

     //notif proxies
     trap(...args){
         // pretrap code
     }

In both case, the same return result needs to be allocated and passed to 
whoever the trap caller was.

# With post-trap case:
     // direct proxies
     trap(...args){
         // pretrap code
         var ret = Reflect.trap(...args)
         // post-trap code
         return ret;
     }

     // notif proxies
     trap(...args){
         // pretrap code
         return () => {
             // post-trap code
         }
     }

In the last snippet, the engine has to store the result of 
Reflect.trap(...args) internally, but that's not worse than storing it 
in a variable as it would currently be the case. I think that having 
this storage internal may even open the door to optimizations that would 
be harder if not impossible to achieve with current proxies.
Thinking about it more, since the posttrap can't modify the return 
value, it can be seen like a "finally" block. So return-value related 
allocation characteristics of a notif proxy with a post trap are 
comparable to the allocation characteristics of:

     function f(){
         try{
             return 'https://www.youtube.com/watch?v=08WeoqWilRQ'
         }
         finally{
             console.log('finally')
         }
     }

David


>
> /be
>
> Mark S. Miller wrote:
>> On Sun, Feb 3, 2013 at 7:22 AM, David Bruant <bruant.d at gmail.com 
>> <mailto:bruant.d at gmail.com>> wrote:
>>
>>     [...]
>>     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 mentioned at the January meeting that we'll be experimenting with 
>> these new notification proxies, to see if they cover all the 
>> motivating use cases adequately. I'm increasingly hopeful, but have 
>> nothing to report yet. If they do, then at the March meeting I will 
>> propose that we do not include direct proxies in ES6. Since it is too 
>> late to introduce as radical a change as notification proxies into 
>> ES6, I would propose that proxies as a whole get postponed till ES7.
>>
>> We'll all be sad to see proxies wait. But given how much better 
>> notification proxies seem to be, if they work out, it would be a 
>> terrible shame to standardize the wrong proxies in ES6 just because 
>> they're ready and sorely needed. Of course, as with Object.observe, 
>> implementors are free to ship things ahead of formal standardization. 
>> And notification proxies are vastly simpler to implement correctly 
>> than direct proxies.
>>
>> -- 
>>     Cheers,
>>     --MarkM
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss