I wonder what was breaking, specially after showing there were
inconsistencies between browsers. Yet nobody wrote a use case where a dev
explicitly marks a callback as strict **expecting** to receive a global
context in it once passed without bind to a setTimeout or setInterval ...
Anyway, thanks
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
Spinning off a new thread...
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark S.
Miller
Subject: RE: use strict VS setTimeout
Let's just be sure that we avoid this mistake when promises grow something
like Q's Q.delay. Promise.delay? Promise.prototype.delay?
IMO
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
18 matches
Mail list logo
