"use strict" VS setTimeout

Mark S. Miller erights at google.com
Mon Sep 8 08:45:21 PDT 2014

On Mon, Sep 8, 2014 at 8:35 AM, Andrea Giammarchi <
andrea.giammarchi at 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 provide. One of the design constraints on WebIDL is
"can it be implemented in JS, perhaps by a proxy?" Exotic object behavior
that cannot be implemented even by proxies is held with great suspicion,
though some of this remains.

So I would generally avoid having the engine observably make a test that JS
can't do. Again, one of these remains as well: a magical sloppy.caller
can't reveal a non-sloppy caller.

> 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}());
> ```

That test only one's own lexical scope. It does not test a function value
given to you across an API boundary.

> 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


Please do file bugs on these and post the links. Thanks.

> 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/a1abafdc/attachment.html>

More information about the es-discuss mailing list