Notification proxies (Was: possible excessive proxy invariants for Object.keys/etc??)

David Bruant bruant.d at
Sun Dec 2 08:43:43 PST 2012

Le 02/12/2012 17:27, Tom Van Cutsem a écrit :
> 2012/11/28 David Bruant <bruant.d at <mailto:bruant.d at>>
>>     I don't understand why a unique token per trap invocation would
>>     be necessary.
>     I still don't understand this point.
>     I've gone spelunking. I've found:
>     * the wiki page [1] (reflecting July meeting) which mentions that
>     returning undefined would express "I don't know the private name,
>     please forward"
>     * Confirmed on July 31st [2].
>     * Introduction of the idea of putting the verification of known
>     names somewhere else than for each trap return [3]. Some
>     discussion in between about this idea. Introduction of the idea of
>     adding a third argument [4] after which I think stops all
>     discussions about returning something in traps to prove knowledge
>     of a private name or forwarding when not knowing.
>     I don't remember the point about a token per trap invocation and I
>     haven't been able to find it (but I haven't read everything).
>     In any case, for "throw ForwardToTarget", I don't see why it would
>     be necessary. It seems it would work unambiguously with
>     meta-handlers, with target-as-a-proxy or with
>     manipulate-any-other-proxy-inside-a-trap (which target-as-a-proxy
>     is an instance of).
> I think throwing a special token, as is done with StopIteration would 
> probably work in practice (little risk of confusing it with a 
> legitimately returned value). However, it does require every trap 
> invocation to be wrapped in a try-catch block to potentially catch 
> that error.
Yes and no. The "try-catch" is inside the engine, very much like for 
StorIteration in for-of loops.
In case current implementations had performance drawbacks, I feel they 
could special-case when they know they are calling a function in the 
context of a particular protocol (iterator or proxy trap for instance).

> Maybe I'm too influenced by the JVM, but my understanding is that 
> wrapping every call to a trap with a try-catch block won't be free.
The more interesting question is whether it would be significantly 
cheaper than 'returning a value+invariant checks' because that's the 
reason I suggested the addition of "throw ForwardToTarget".

> Perhaps implementors can comment.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list