<div class="gmail_quote">2011/7/28 Andreas Rossberg <span dir="ltr"><<a href="mailto:rossberg@google.com">rossberg@google.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 28 July 2011 10:35, David Bruant <<a href="mailto:david.bruant@labri.fr">david.bruant@labri.fr</a>> wrote:<br> > I think we discussed already the idea of "proxy" being passed as a data<br>

> property to the handler and came to the conclusion that it may not be a good<br>
> idea, because it breaks the stratification. If two proxies use the same<br>
> handler as in [2], then, there is an ambiguity on what the value of this<br>
> property should be.<br>
<br>
</div>The solution we discussed is to simply use prototypes. That is, share<br>
handler methods by putting them on a (single) prototype object, and<br>
have per-proxy instances that carry the individual proxy references<br>
(or other per-proxy data, for that matter).</blockquote><div><br></div><div>I agree that's a good pattern to achieve application-specific per-proxy handler state, but it doesn't standardize the proxy-backlink, so handler authors cannot in general rely on the existence of e.g. a |handler.proxy| property. That precludes the two use cases outlined in my previous mail, which relate to generic trap code that should work with any proxy handler.</div>
<div><br></div><div>Cheers,</div><div>Tom</div></div>