"use strict" VS setTimeout

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Sep 8 08:35:56 PDT 2014


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 = isStrictAvailable && (function(){return !this}());
```

Btw, I laughed hard than I've should have on this:

> "Now it just happens that Blink, IE and WebKit (or at least Safari) have
buggy requestAnimationFrame implementations."

Best Regards


On Mon, Sep 8, 2014 at 3:41 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> 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 looks like at the end of the
>> day only things to improve/change are:
>>
>> requestAnimationFrame
>> setInterval
>> setTimeout
>>
>
> requestAnimationFrame doesn't have this problem.  See <
> http://www.w3.org/TR/animation-timing/#dfn-invoke-callbacks-algorithm>
> and the text about "callback this value" at <http://heycam.github.io/
> webidl/#es-invoking-callback-functions>: it defaults to undefined unless
> specified otherwise, and the requestAnimationFrame spec doesn't specify
> otherwise.  You can see a testcase for this behavior at
> http://jsfiddle.net/xpwr1ozx/
>
> Now it just happens that Blink, IE and WebKit (or at least Safari) have
> buggy requestAnimationFrame implementations.  Specifically, Blink and IE
> pass a Window as "this" (I didn't check which Window) and WebKit passes the
> function itself as "this" as far as I can tell(!).  Firefox follows the
> spec and passes undefined.  Please feel free to file bugs on the other
> implementations!
>
>  Although I have honestly no idea how to explain via W3C pages that JS
>> might be strict or not ... seems to me that "_strictness_" should be
>> outside the DOM knowledge so .... probably this should be part of ES
>> specification.
>>
>
> The normal way this would be done is that ES would expose an abstract
> operation that returns true or false for strictness of a function and then
> DOM would invoke that abstract operation.  Though obviously the DOM could
> just directly check the [[Strict]] internal slot too if there is no
> abstract operation defined for it.
>
> -Boris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140908/f7c02b7e/attachment.html>


More information about the es-discuss mailing list