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

Tom Van Cutsem tomvc.be at gmail.com
Sun Dec 2 08:27:31 PST 2012


2012/11/28 David Bruant <bruant.d at gmail.com>

>  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. 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. Perhaps implementors can
comment.

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


More information about the es-discuss mailing list