On 2/3/14 1:19 PM, Allen Wirfs-Brock wrote:
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.
Yes, indeed. Welcome to the world most spec authors operate in most of
the time: they have to deal with concepts and assumptions that they
don't know much, if anything, about.
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.
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?
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.
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.
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
