On Feb 3, 2014, at 11:30 AM, Boris Zbarsky wrote: > On 2/3/14 1:19 PM, Allen Wirfs-Brock wrote: >> ... > >> For example, what is a location and what does bind have to do with anything? > > bind is needed here only because the functions involved throw if their "this" > value is not correctly branded. Since the APIs being called just call a > function, with undefined this value, you have to pass in a bound version of > the function to get anything other than an exception to happen.
Do me this seems style should be considered an anti-pattern as the then contract is for a function that does not require a this value. They could be more concisely and clearly restated as: 1): somePromise.then(() => window.postMessage(5, "*")); 2): somePromise.then(() => location.href = "relativeURI"); Am I misunderstanding something about these? > >> In ES semantic, all bind does is is create a filtering mechanism that passes >> a fixed value to the target function. > > Right, that's all I need it for here. > >> 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? > > Possibly, yes. > > Do Realms have associated origins and base URIs? Those are the concepts that > are relevant here. Some DOM functions need some ambient concept of origin > and base URI to do what they do. In a single-global world there is no > problem: you just use the origin and base URI of that global. But in a > multiple-global world you have to define which global's origin and base URI > is used. The situation is complicated by the fact that for the base URI case > there are backwards compatibility constraints (which would clearly not apply > to Realms per se, but do apply to iframes). > > If Realms have those concepts associated with them? Realms don't directly expose those concepts (that would be pretty host platform dependent) but they do have a global object upon which properties can be predefined and they allow for association with a Loader that might be host specific and have such state. see http://people.mozilla.org/~jorendorff/es6-draft.html#sec-code-realms > >> Are you suggesting that all uses of ECMAScript promises in all hosting >> environments must have a dependency upon WebIDL callback semantics? > > There are two relevant answers here. > > Answering the question directly: yes, since the only interesting callback > semantic that a WebIDL "callback Function = any(any... args)" has is that it > maintains this script settings object stack that's consumed by DOM APIs; if > your hosting environment doesn't have those APIs then it's black-box > indistinguishable from direct invocation of the [[Call]] of the function > object in question. So the dependency only affects behavior when you're > exposing DOM APIs. > > But the real answer is probably more that this dichotomy between "ES" and > "WebIDL" needs to go, and we should define ES callback semantics that WebIDL > can then rely on, which expose hooks that DOM can use to maintain the state > it needs. If there needs to be hooks (in [[Call]] or anywhere else) we should be able to describe those hooks in a way that is meaningful and offer potential utility to other kinds of hosts. How would you abstractly describe you requirements? > >> What I most don't understand about all of the above is what F.p.bind has to >> do with all of this? > > It just makes the testcases actually do something instead of throwing. Unless I missed something, the use of bind just obscured the point you were really trying to make. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
