2012/11/28 David Bruant <bruan...@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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
