<div class="gmail_quote">2012/10/20 Axel Rauschmayer <span dir="ltr"><<a href="mailto:axel@rauschma.de" target="_blank">axel@rauschma.de</a>></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div>Currently, proxies make no distinction between a property read access and a method invocation. In my experience, it would be nice if that distinction would be there Ė if only that one didnít have to curry for method invocations which must be a performance issue and is a fairly common use case (remotely invoking web services etc.). Now, there are reasons against this and Iím mainly wondering if actually using the new API has changed your or Tomís mind.</div>
</div></div></blockquote><div><br></div><div>I agree there are use cases for distinguishing method invocations from property accesses (remote method calls are one of them -- you'd want to distinguish between doing an HTTP GET vs POST). But the new API hasn't changed the balance for or against an "invoke" trap. Recall that one of the reasons was that an "invoke" trap would lead to invoke-only methods, which goes against functional programming patterns in Javascript (e.g. people expect array.map(obj.method) to work)</div>
<div><br></div><div>Cheers,</div><div>Tom</div></div>