On 2/3/14 6:45 PM, Allen Wirfs-Brock wrote:
I'm not sure that I see the difference.
That's fair. In SpiderMonkey's implementation there is a difference:
bind is not a "scripted" function associated with actual user script,
while an arrow function (and any other function actually defined in a
script) is.
Are you assuming something about the "origin" of built-ins such as ES5 bind?
No. On the contrary, I'm assuming that foo.bind(thisval,
args).call(undefined) and foo.call(thisval, args) and thisval.foo(args)
should all behave identically in terms of things like origins and base
URIs. As should setTimeout(foo.bind(thisval), 0, args), for that matter.
In ES6 all functions, including built-ins are permanently associated with a
Realm when they are created.
Yes. That plus every global having an origin gives us the concept of
origin of a function, which is well defined. And that's useful and used
for things. But it doesn't match what postMessage needs to do, because
if my code does:
otherWindow.postMessage(args)
then the origin of the message is my code, not otherWindow...
I'm not sure whether that's in fact the behavior we want for arrow functions...
but certainly in general if I have some code in window A that calls then() and
passes to it a function from window B that then calls postMessage on window C,
we want the message to be coming from B, not from A. Or so I'm told.
Yes, that's how it would functions, but I don't think that bind really changes
anything.
It simply makes it possible to invoke a "native" (that is,
browser-provided) function directly from the event loop without any user
code on the stack.
The arrow function (or the call to bind) could have taken in the context of B
before being passed to A. In that case, the call to postMessge will be coming
form B.
I'm honestly not sure what you're arguing here.
In ES6 we are introducing asynchronous tasks (needed to support promise, but
someday probably also events) and I'm trying to be careful to make sure it is
well specified which Realm each async task initially represents.
Ah. To support the things DOM needs you need to associate at least two
possibly-distinct realms to each task, I believe. Those are the
"incumbent" and "entry" globals (or "script settings objects", as one
prefers).
In either case, most task immediate call a JS function so that's probably where
realm (or origin??) crossing actually takes place.
That would chance the incumbent global. What it does on the entry
global depends. Generally, calling a JS function doesn't change the
entry global; WebIDL callbacks should be explicitly changing it before
calling their callback function...
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
