[[Invoke]] and implicit method calls
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss