On Feb 3, 2014, at 9:53 AM, Boris Zbarsky wrote: > On 2/3/14 12:35 PM, Anne van Kesteren wrote: >> Could you maybe give an explicit example? I think that would help in >> understanding the bug in the promises specification. I suspect not >> everyone here is familiar with what you are referring to. > > Sure. Given a promise named "somePromise", something needs to define the > behavior of the following two cases: > > 1) somePromise.then(window.postMessage.bind(window, 5, "*")); > > 2) var set = Object.getOwnPropertyDescriptor(location, "href").set; > var navigate = set.bind(location, "relativeURI"); > somePromise.then(navigate); > > The incumbent settings object (aka "the script you were called from") defines > the behavior of case #1: it determines the .origin property of the resulting > MessageEvent. > > The entry settings object (aka "that weird backwards-compat thing Location > needs, which is kinda where you entered JS execution from browser code, > whatever that means") defines the behavior of case #2: it determines the base > URI used for resolving the "relativeURI" string. > > My real point was that we don't want to make every single specification > writer worry about edge cases like this and various other ones scattered > about the web platform unless we absolutely have to. Especially since the > "sane" behavior in the cases above is not trivially obvious.
It's hard to even talk about this because the above is filled with concepts and assumptions that don't currently occur anywhere in the ES specification. For example, what is a location and what does bind have to do with anything? In ES semantic, all bind does is is create a filtering mechanism that passes a fixed value to the target function. ES6 does provide the concept of Realms (approximately a global environment) and a immutable association between scripts/functions and Realms. Is it possible to frame the discussion in those terms? > > -Boris > > P.S. For the record, if Promise.prototype.then took a WebIDL callback as an > argument the behavior would be as follows: > > In case 1 the origin is the origin of the incumbent settings object at the > time the "then()" call was made. If that happened from a script, it's the > origin of that script; if it happened via more bind/callback games then it > depends on what those callbacks pushed on the script settings stack. > > In case 2 the base URI is the base URI of the global associated with the > "navigate" Function object. Are you suggesting that all uses of ECMAScript promises in all hosting environments must have a dependency upon WebIDL callback semantics? > > P.P.S. You can add some curliques to case #2 by grabbing the setter from one > global, the location object from a second global, calling > Function.prototype.bind from a third global, having the promise come from a > fourth global, having the "then" method come from a fifth global and binding > it to the promise using Function.prototype.bind from a sixth global. Just to > keep people on their toes and all. What I most don't understand about all of the above is what F.p.bind has to do with all of this? Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
