If we don't end up emails with questions, maybe? :P
Thanks Boris for the improved report bug in webkit.
Best Regards
Sent from my Windows PhoneFrom: Brendan Eich
Sent: 9/9/2014 0:10
To: Andrea Giammarchi
Cc: Mark Miller; Mark S. Miller; es-discuss list
Subject: Re: use strict VS setTimeout
Subject: Re: use strict VS setTimeout
On Sun, Sep 7, 2014 at 6:35 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/7/14, 1:29 PM, Andrea Giammarchi wrote:
I know this is probably W3C land but the following code shows the global
object
Careful with your use of the word the. Your ES5-centric
On 9/8/14, 3:50 AM, Andrea Giammarchi wrote:
I wonder what was breaking
I don't remember, unfortunately. :(
specially after showing there were
inconsistencies between browsers.
It's worth asking the IE team whether they changed because of concrete
web compat issues or just to align with
no introspection or nothing magic and weird, simply `.call(undefined)`
would do for sloppy and strict, preserving global in sloppy, avoiding
shenanigans in strict.
Hence my curiosity: when this experiment was made, which code with `use
strict` failed ? 'cause that would be the only one that
On 9/8/14, 8:15 AM, Andrea Giammarchi wrote:
no introspection or nothing magic and weird, simply `.call(undefined)`
would do for sloppy and strict, preserving global in sloppy, avoiding
shenanigans in strict.
You seem to be assuming there is only one global involved again. Did
you look at my
Apologies, now I see what you meant and I think option 2 would be probably
ideal. ES5+ engines can easily retrieve strictness so while it might seem
weird it would surprise less, syntax and explicit intent speaking, and will
remove the right to pass *a* global context to the callback.
Going
On Mon, Sep 8, 2014 at 7:25 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Apologies, now I see what you meant and I think option 2 would be probably
ideal.
I disagree. I think option #2 is rather horrible. Strictness can't be
tested in JS user code, and shouldn't be. And sloppy
On 9/8/14, 10:25 AM, Andrea Giammarchi wrote:
Apologies, now I see what you meant and I think option 2 would be
probably ideal. ES5+ engines can easily retrieve strictness
In script? How? (Again, clearly in the VM implementation I can do this.)
Going through the list of all properties it
Boris and Mark, I was talking about engines, already inevitably able to
distinguish strict from sloppy, but in any case in JS is straight forward
to know if you are under strict directive or not.
```js
var isStrictAvailable = (function(){'use strict';return !this}());
var isThisStrict =
On Mon, Sep 8, 2014 at 8:35 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Boris and Mark, I was talking about engines, already inevitably able to
distinguish strict from sloppy,
We have made great progress in JS better able to implement/emulate the APIs
we expect browsers to
No, this isn't an information disclosure or any other security issue. It is
only a modularity issue.
On Mon, Sep 8, 2014 at 9:49 AM, Jasvir Nagra jas...@gmail.com wrote:
On Mon, Sep 8, 2014 at 8:45 AM, Mark S. Miller erig...@google.com wrote:
On Mon, Sep 8, 2014 at 8:35 AM, Andrea
Mark Miller wrote:
Yes, this is indeed the only question that Andrea and I are raising in
this thread. As you acknowledge, providing window here is a little
strange. I quibble with a little. When a surprise surprises by
providing less authority than expected, I don't much care. When the
Thanks for the background history, however I am still not sold the fact
it's a global object method should mean a global context should be passed.
Following, a snippet simulating what would be my expectations
```js
window.myTimer = function (callback, delay) {
// queue the callback as the task
On Mon, Sep 8, 2014 at 3:15 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Thanks for the background history, however I am still not sold the fact
it's a global object method should mean a global context should be passed.
Following, a snippet simulating what would be my
Andrea Giammarchi wrote:
Thanks for the background history, however I am still not sold the
fact it's a global object method should mean a global context should
be passed.
Is (or was and therefore is because don't break the web) -- not
ought.
You need a way out of Hume's Guillotine on the
On 9/8/14, 6:49 PM, Mark S. Miller wrote:
Let's just be sure that we avoid this mistake when promises grow
something like Q's Q.delay. Promise.delay? Promise.prototype.delay?
Yes, absolutely. This is why requestAnimationFrame is specced to pass
undefined for this, implementation bugs
On 9/8/14, 7:10 PM, Brendan Eich wrote:
The point here is that otherWin.setTimeout(func, ...) must -- because of
is not ought -- not pass undefined to func in case it is strict
mode, because if it's sloppy and if it is scoped by the current window
(not otherWin), then the wrong window will be
Boris Zbarsky wrote:
Though again, IE9 and before use that wrong window. So it's at least
_possible_ that UAs could change to that behavior (change back, in the
case of IE).
What, my original intent argument didn't work? :-P
On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
This looks like a potential problem when possible passed methods are not
bound + it looks inconsistent with *use strict* expectations.
It’s not just `setTimeout` – other DOM timer methods have the same
Fair enough, I was looking for that part indeed but couldn't find anything
explicitly related in here:
http://www.w3.org/TR/2011/WD-html5-20110525/timers.html
Thanks!
On Sun, Sep 7, 2014 at 6:36 PM, Mathias Bynens mathi...@opera.com wrote:
On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
On Sun, Sep 7, 2014 at 10:36 AM, Mathias Bynens mathi...@opera.com wrote:
On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
This looks like a potential problem when possible passed methods are not
bound + it looks inconsistent with *use strict*
`
var temp = window;
document.querySelector('iframe').contentWindow.setTimeout(function() {
console.log(temp === window); // false
})
`
setTimeout is a method of global object, not a standalone function.
2014-09-07 19:47 GMT+02:00 Mark S. Miller erig...@google.com:
On Sun, Sep 7, 2014 at 10:36
My same thoughts on break the web ... I think whoever put use strict in
there would eventually never expect the `this` to be the global context.
@Michał Wadas ... you haven't proved much in there ... you should look at
global methods more like this:
```js
// your global context to be executed
On Sep 7, 2014, at 19:47 , Mark S. Miller erig...@google.com wrote:
On Sun, Sep 7, 2014 at 10:36 AM, Mathias Bynens mathi...@opera.com wrote:
On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
This looks like a potential problem when possible passed methods
On Sun, Sep 7, 2014 at 10:29 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I know this is probably W3C land but the following code shows the global
object in every JS engine I could test:
```js
(function () {
'use strict';
setTimeout(function () {
'use strict';
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
On Sun, Sep 7, 2014 at 11:07 AM, Andrea Giammarchi
andrea.giammar...@gmail.com 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 () {
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
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
I would add that in node.js it returns neither undefined nor window, but a timer object, which you can clear up with `clearInterval(this)` inside the callback. 07.09.2014, 21:30, "Andrea Giammarchi" andrea.giammar...@gmail.com:I know this is probably W3C land but the following code shows the
; es-discuss
listmailto:es-discuss@mozilla.org
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 Sun, Sep 7, 2014 at 11:27 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I don't understand why this is any more surprising than any other
function that calls its callback with .call(something).
The issue is what the something should be, and which choices for something
are
On Sun, Sep 7, 2014 at 11:44 AM, Garrett Smith dhtmlkitc...@gmail.com
wrote:
On 9/7/14, Domenic Denicola dome...@domenicdenicola.com 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
es-discuss@mozilla.org
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
Giammarchimailto:andrea.giammar...@gmail.com
Sent: ?2014-?09-?07 19:14
To: Mark Millermailto:erig...@gmail.com
Cc: Mark S. Millermailto:erig...@google.com; es-discuss
listmailto:es-discuss@mozilla.org
Subject: Re: use strict VS setTimeout
It feels to me also a vector that will happily pass all linters and code
On 9/7/14, Mark Miller erig...@gmail.com wrote:
On Sun, Sep 7, 2014 at 11:27 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I don't understand why this is any more surprising than any other
function that calls its callback with .call(something).
The issue is what the something
...@gmail.com
Sent: 2014-09-07 19:14
To: Mark Miller erig...@gmail.com
Cc: Mark S. Miller erig...@google.com; es-discuss list
es-discuss@mozilla.org
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
On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I know this is probably W3C land ...
First hit for callback use strict inurl:lists.w3.org:
http://lists.w3.org/Archives/Public/public-script-coord/2011JulSep/thread.html#msg3
--
http://annevankesteren.nl/
Yes Anne, reason I've posted here was to ask opinions from JS land + I am
not sure it's that easy to post in W3C mailing list as random chap while
here I'm already registered (and here I was looking for opinions beside
what specs say)
Good to see MM was already on fire in there :D
On Sun, Sep 7,
On Sun, Sep 7, 2014 at 9:06 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Yes Anne, reason I've posted here was to ask opinions from JS land + I am
not sure it's that easy to post in W3C mailing list as random chap while
here I'm already registered (and here I was looking for
I might try again but they'll probably tell me specs say so, must be good
as others here so not sure I should bother.
Thanks though.
Regards
On Sun, Sep 7, 2014 at 8:11 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Sep 7, 2014 at 9:06 PM, Andrea Giammarchi
andrea.giammar...@gmail.com
On 9/7/14, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
**implicitly fail** from a user point of view that used use strict to
avoid receiving the global context in there ... I am not sure how much you
want to turn it back to me but you are missing the point and I've not much
else to
this is getting nowhere ... yeah Garret, you can use `.call` and we all
know that ...
Now I want you to answer this: why on earth would you expect a global
context in a setTimeout or setInterval operation for a function/method you
have explicitly defined as strict ?
One single use case ... do
On 9/7/14, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
this is getting nowhere ... yeah Garret, you can use `.call` and we all
know that ...
Now I want you to answer this: why on earth would you expect a global
context in a setTimeout or setInterval operation for a function/method
On Sun, Sep 7, 2014 at 12:50 PM, Garrett Smith dhtmlkitc...@gmail.com
wrote:
On 9/7/14, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
this is getting nowhere ... yeah Garret, you can use `.call` and we all
know that ...
Now I want you to answer this: why on earth would you expect
On 9/7/14, 1:29 PM, Andrea Giammarchi wrote:
I know this is probably W3C land but the following code shows the global
object
Careful with your use of the word the. Your ES5-centric assumptions
are showing. ;)
The function passed to setTimeout will be invoked with this set to the
window
On Sun, Sep 7, 2014 at 6:35 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/7/14, 1:29 PM, Andrea Giammarchi wrote:
I know this is probably W3C land but the following code shows the global
object
Careful with your use of the word the. Your ES5-centric assumptions are
showing. ;)
The
On 9/7/14, 9:35 PM, Boris Zbarsky wrote:
Now, and here's where I have a problem with your use of the: the
Window that setTimeout is invoked on is NOT necessarily the same as the
global object of the function.
Just to make this concrete, see
http://fiddle.jshell.net/tmt5e9m6/2/show/ which has
48 matches
Mail list logo
