On Sep 7, 2014, at 19:54, "Andrea Giammarchi"
<[email protected]<mailto:[email protected]>> wrote:
But here I go back to the utopia I've already mentioned on putting everyone
together to fix this, and I'm fine if it won't change but it's good to know
that "use strict" could implicitly fail when the DOM is involved.
To be clear, "use strict" is not failing; it's not like the DOM APIs are doing
anything against the JS spec. That is, I wouldn't say that `function f(g) {
g.call({}); }` makes "use strict" fail.
As for knowing that sometimes DOM APIs call passed-in functions with a thisArg,
you should probably already be used to that from addEventListener.
Regards
On Sun, Sep 7, 2014 at 7:27 PM, Domenic Denicola
<[email protected]<mailto:[email protected]>> wrote:
I don't understand why this is any more surprising than any other function that
calls its callback with .call(something). It doesn't matter whether the
callback is strict or not; .call(window), which is what the spec does, will
override it.
As far as I can see this issue has absolutely nothing to do with strict vs.
sloppy.
________________________________
From: Andrea Giammarchi<mailto:[email protected]>
Sent: ?2014-?09-?07 19:14
To: Mark Miller<mailto:[email protected]>
Cc: Mark S. Miller<mailto:[email protected]>; es-discuss
list<mailto:[email protected]>
Subject: Re: "use strict" VS setTimeout
It feels to me also a vector that will happily pass all linters and code
analyzers giving users a door to reach native context and start playing in
there with everything else. I'm pretty sure you would agree on this too :)
Please let us know if there's any follow up, it's probably easier/faster if
some googler mention this issue to other googlers that are collaborating with
WHATWG or W3C or both (or none)
Thanks
On Sun, Sep 7, 2014 at 7:11 PM, Mark Miller
<[email protected]<mailto:[email protected]>> wrote:
On Sun, Sep 7, 2014 at 11:07 AM, Andrea Giammarchi
<[email protected]<mailto:[email protected]>> wrote:
Yes Axel, that's how it works, this will show undefined indeed all over
```js
(function () {
'use strict';
function g() {
console.log(this);
}
g(); // undefined
setTimeout(function () {
g(); // undefined
}, 0);
}());
```
or testing other use strict restrictions:
```js
(function () {
'use strict';
setTimeout(function () {
argument.callee
}, 0);
}());
```
The strict behavior is preserved, it's not an opt-out, but the invoked function
within setTimeout has the global context regardless it has been defined under
the strict directive + regardless it defines itself as strict.
Basically if you feel secure about "use strict" here you have a case that shows
you shouldn't ... making one point of strict directive kinda broken/pointless.
Agreed. I would remove only "kinda" from that statement ;).
Regards
On Sun, Sep 7, 2014 at 7:02 PM, Axel Rauschmayer
<[email protected]<mailto:[email protected]>> wrote:
On Sep 7, 2014, at 19:47 , Mark S. Miller
<[email protected]<mailto:[email protected]>> wrote:
On Sun, Sep 7, 2014 at 10:36 AM, Mathias Bynens
<[email protected]<mailto:[email protected]>> wrote:
On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
<[email protected]<mailto:[email protected]>> wrote:
> This looks like a potential problem when possible passed methods are not
> bound + it looks inconsistent with *"use strict"* expectations.
Yes. This looks like a typical screwup. Thanks for pointing it out.
Interesting. Follow-up question: isn't strictness propagated lexically? That
is, shouldn't the parameter of `setTimeout()` be strict even without being
explicitly declared as such?
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
