A few arrow function specification issues

John J Barton johnjbarton at johnjbarton.com
Mon Apr 23 17:22:55 PDT 2012

Ok I gotta testify for the other side: use strict is not all roses. I hit
three problems with 'use strict':

1. I wrote the following code in JavaScript:

function register(otherWindow, local, options) {

    var remote = Q_COMM.Connection(otherWindow, local, options);

    remote.discover = function (remoteName) {...}

   return remote;

Upon calling the function I was surprised to find remote.discover was not
set.  After a long debug session I discovered that Q_COMM had frozen
'remote', but in order for me, the library user to get an error message I
had 'use strict'. In my opinion this is a bug.

2. Web Inspector has a bug related to use strict:

 3. The typical solution for obtaining a reference to the global object:

var global = (function() { return this; })();

fails in 'use strict'. As Domenic tells me, you have use

var global = Function('return this')();

These are not fundamental problems with 'use strict', they are practical
problems caused by fragmenting the language in to modes.


On Mon, Apr 23, 2012 at 5:11 PM, Anton Kovalyov <ml at kovalyov.net> wrote:

> My two cents. A little over a year ago, I went over our JavaScript code
> here at Disqus and made sure that 99% of it is in strict mode. This was
> definitely a code cleanup aiming at catching variable leaks and other small
> bugs.
> --
> Anton Kovalyov
> Sent with Sparrow <http://www.sparrowmailapp.com/?sig>
> On Monday, April 23, 2012 at 4:59 PM, Domenic Denicola wrote:
> As a day-to-day user who was not using strict until recently (stubborn
> other team member for the loss), I can say that moving to strict was much
> more a "cleanup" experience than a "mode" experience, with only a few small
> exceptions:
> 1) Poison-pilling arguments.callee: some code on the internet (notably
> [1], but elsewhere too) uses this property.
> 2) Throw on `delete`ing non-configurables: unlike the other
> throw-on-doing-something-bad, `delete`ing non-configurable properties was
> something we actually did on purpose. E.g. using it to clear an "entry" in
> a "map", whether or not that entry was ever filled. (Cf. [2].) We never
> tried writing to a non-writable property, because that would cause bugs,
> but `delete`ing a property that doesn't exist was a common pattern.
> [1]: http://www.devthought.com/2011/12/22/a-string-is-not-an-error/
> [2]:
> https://github.com/cjohansen/Sinon.JS/commit/80c38bd3e4b8813ab74ef27a4db3646e4778e31c
> ---
> Otherwise, it was just cleanup: we got to get rid of our global detector
> (`setInterval(compareWindowPropertiesToLastTimeYouChecked(), 1000)`), never
> missed `with` or evil-`eval`, and due to a V8 bug never had boxed `this` in
> the first place. We're using it transparently throughout the codebase, in
> fact, due to using an XHR+`eval` module loader that can insert the `"use
> strict"` pragma before `eval`ing.
> -----Original Message-----
> From: es-discuss-bounces at mozilla.org [mailto:es-discuss- <es-discuss->
> bounces at mozilla.org] On Behalf Of David Herman
> Sent: Monday, April 23, 2012 19:11
> To: Brendan Eich
> Cc: es-discuss
> Subject: Re: A few arrow function specification issues
> On Apr 23, 2012, at 2:44 PM, Brendan Eich wrote:
> Brendan Eich wrote:
> Without arguments runtime semantic shifts, and with |this| lexical,
> there aren't many strict mode changes left IIRC, and they are pretty edgy
> edge cases.
> True enough, but I hang tough on wanting arrows to imply strictness. I
> may be wrong but the edge cases cited so far (global variable creation by
> assignment, 'with', direct eval injecting 'var' into its dynamic scope)
> along with this |this|-boxing one are underwhelming.
> IMO, this decision hangs on whether we think strict mode can be thought
> of as a "cleaning up" that will mostly just catch bugs, resulting in
> failing faster but otherwise not changing program behavior significantly.
> POSITION "CLEANUP": If it's just a cleanup, then it makes sense to
> introduce strict mode in a bunch of places in the language. It'll catch
> bugs, and for the most part people won't have to think to themselves "is
> this strict code?"
> POSITION "MODE": If it's something that is likely to change behavior in
> meaningful ways other than failing faster, then it's something
> programmers will have to be mindful of. In that case, having multiple
> constructs that implicitly introduce strict mode imposes a burden on
> programmers: they have to know which features are strict and which ones
> aren't.
> Every fiber of my being screams MODE. Brendan argues CLEANUP based on the
> rationale that the non-error semantic changes of strict mode are unlikely
> edge cases. This is the strongest argument against MODE. I can't prove it
> wrong, but it's a risky bet. If it turns out to be the case that in
> practice you need to keep track of whether you're in strict mode, then
> weak programmers who don't know better will end up with a confusing mess,
> and strong programmers will prophylactically make sure to put their
> entire programs in strict mode rather than memorize which subset of
> syntaxes opt in. Since strong programmers have the option to do that
> anyway even without multiple implicit opt-ins, why take the risk?
> Pascal^H^H^H^H^H^H Dave
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120423/3642273d/attachment.html>

More information about the es-discuss mailing list