Re: [[Call]] behaviour of operations

[Sorry for the duplicate Mark, forgot to copy the list.]

Hi Mark.

On 22/08/11 12:49 PM, Mark S. Miller wrote:
 > This approach risks destroying all the progress ES5.1/strict made over
 > ES3 in preventing global object leakage. The window is a singleton. Any
 > method of window that actually needs access to its window when invoked
 > as a function should just lexically capture it. If "alert('foo')" is
 > supposed to do the same thing as "window.alert('foo')",
 > "window.alert.call(window, 'foo')" and "window.alert.call(undefined,
 > 'foo')", then it should do the same thing as
 > "window.alert.call(otherWindow, 'foo')". If alert does not depend on its
 > this-binding at all, then all these will simply be equivalent.

I tested just now which window `window.func.call(otherWindow)` uses:

   http://people.mozilla.org/~cmccormack/tests/window-this-binding.html

This uses window.postMessage as the function to test.  In 
Firefox/Safari/Chrome/Opera doing `window.postMessage.call(otherWindow, 
"test, "*")` sends a message to otherWindow.

I also just tested bare alert(...) and `window.alert.call(null, ...)` in 
strict mode in Firefox/Safari/Chrome, and they all successfully show the 
alert in both cases.

 > Or is it your intention that "window.alert.call(otherWindow, 'foo')" not
 > be equivalent to "alert('foo')" ?

That wasn't a particular intention of the change.

I just wanted the change to make alert(...) do the same thing as 
window.alert(...) in strict mode.

If people think it is safe to make all of the window object's methods 
bind to the window they are grabbed off, then I'm happy to make that 
change.  It is different behaviour from what we have at the moment, though.

Received on Monday, 22 August 2011 04:45:47 UTC