On Feb 3, 2014, at 1:44 PM, Boris Zbarsky wrote:
> On 2/3/14 3:55 PM, Allen Wirfs-Brock wrote:
>> 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.
>
> Sure. No one in their right mind would write it that way. Except insofar as
> they're trying to get particular security behavior...
>
>> 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?
>
> These actually have somewhat different behavior from the bind case.
>
> Specifically, the origin that the postMessage sees in the arrow function acse
> right now will be that of the arrow function passed to then() in this case
> (or whatever JS function it is that invokes postMessage if it's a JS function
> with actual JS code that invokes it). This is not necessarily the same as
> the origin of the code that called then()...
I'm not sure that I see the difference. You can think of bind as if it was
defined as:
function bind(boundThis, ...boundArgs) {return
(...perCallArgs)=>this.call(boundThis,...boundArgs,...perCallArgs)};
this isn't exactly how ES defines it but it is conceptually what is happening
and what frameworks actually did (of course not uses => and ...) prior to ES5.
Are you assuming something about the "origin" of built-ins such as ES5 bind?
In ES6 all functions, including built-ins are permanently associated with a
Realm when they are created. In the case of an arrow functions, their realm is
the same as the realm of the code that contains the arrow expression.
>
> 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. 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.
>
>> 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.
>
> OK, great. ;)
>
>> 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?
>
> Requirement #1: When some actual JS code someone typed into a <script> tag
> calls postMessage on some Window object, the origin needs to be the origin of
> the JS code in question.
>
> Requirement #2: When some actual JS code someone typed into a <script> tag
> calls the location.href setter, the base URI needs to be the thing that's
> compatible with what UAs do (which in practice means "the base URI of the
> window where we last called from C++ into JavaScript)... Yes, this sucks, I'm
> sorry.
>
> Requirement #3: We need to extend these definitions to all cases where these
> functions can be called, even if there is no actual script someone typed into
> a <script> tag that is calling them.
>
> I'm not sure how to describe all this for an environment that doesn't have
> postMessage or a location setter, honestly. In particular, the location
> setter behavior is purely compat with insanity. :(
Yes, the above is so specific and operational, it is hard to generalize into
more abstract concepts. But I'm sure it can be done.
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18242 has some of the relevant
> discussion, if that helps, for the postMessage case.
>
>> Unless I missed something, the use of bind just obscured the point you
>> were really trying to make.
>
> I needed a way to have the browser asynchronously invoke the method in
> question in a context where the phrase "script that invoked the method"
> (which is what postMessage used to be defined in terms of) is nonsensical.
> Unfortunately, in the arrow function case it's perfectly well-defined what
> the "script that invoked the method is", so the arrow function version
> doesn't actually exercise the edge case I wanted to exercise.
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. If the task
is created (perhaps, indirectly) from JS code then it is the realm of the JS
code that is the creator. If the task is created by an external, non-JS agent,
then the initial realm of the task must be explicitly provided. In either
case, most task immediate call a JS function so that's probably where realm (or
origin??) crossing actually takes place.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
