[[Invoke]] and implicit method calls

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Sep 19 05:39:45 PDT 2013


On Sep 19, 2013, at 8:25 AM, Tom Van Cutsem wrote:

> 2013/9/19 Brendan Eich <brendan at mozilla.com>
> Refactoring [[Get]]+[[Call]] to [[Get]]+[[Invoke]] seems fine by me. It better expresses the intent, and the change should only be observable to proxies.
> 
> Is this so? Wouldn't an ordinary object with a getter be able to observe the two lookups? Indeed wouldn't the spec require this?
> 
> You're right. The change would lead to observably different behavior for conditionally invoked getters.
> 
> Not sure how much of a backwards compat issue that would be. Allen previously wrote upstream in this thread:
> 
> There are currently 6 such places (not counting the Proxy trap invocators):
> 3 in ToPrimitive (ie toSrting/valueOf)
> 1 in instanceof to access @@hasInstance (legacy conpat. for missing @@hasInstance)
> 1 in [ ].toString to conditionally invoke 'join' method
> 1 in JSON.stringify conditionally invoke 'toJSON'
> 
> How likely is it that these are getters with side-effects?

Seems very unlikely.  The @@hasInstance access is new so it isn't a backwards compat issue.   BTW, these are static counts. For example, a typical call to ToPrimitive will only make a single such conditional invoke.

Arguably allowing a String or Number wrapper to be transparently proxied and hence work like a unproxied wrapper WRT ToPrimitive is one the reasons we need to do this.

Allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130919/83e2473c/attachment.html>


More information about the es-discuss mailing list