"use strict"; prepended blindly to scripts in the wild

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Wed Sep 15 06:15:44 PDT 2010


  On 15.09.2010 2:24, Allen Wirfs-Brock wrote:
>
> The note in section 14.1 advises: "If an appropriate notification 
> mechanism exists, an implementation should issue a warning if it 
> encounters in a Directive Prologue an ExpressionStatement that is not 
> a Use Strict Directive or which does not have a meaning defined by the 
> implementation."
>
> It sounds like it would also be a good idea for implementations to 
> issue such a warning if an "use string" expression statement appears 
> anywhere at the global level that is outside of the Directive Prologue.
>

If these consequences are acceptable:

1. It may bring such warnings for old scripts (any "string"; appeared in 
the source will be treated as a potential issue for the notifier);
2. It won't be possible (without a warning) also to combine two scripts 
with "use strict" at the global level;
3. and it won't be possible (without a warning) to use the mentioned 
workaround with inserting an empty statement at the beginning,

then it's possibly OK. The most important, though, is the first point 
(regarding again backward compats).

Dmitry.

> *From:* es-discuss-bounces at mozilla.org 
> [mailto:es-discuss-bounces at mozilla.org] *On Behalf Of *Dmitry Soshnikov
> *Sent:* Thursday, September 09, 2010 11:57 AM
> *To:* Brendan Eich
> *Cc:* es-discuss at mozilla.org
> *Subject:* Re: "use strict"; prepended blindly to scripts in the wild
>
> On Thu, Sep 9, 2010 at 9:35 PM, Brendan Eich <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> wrote:
>
> On Sep 9, 2010, at 10:33 AM, Dmitry Soshnikov wrote:
>
>
>
> On Thu, Sep 9, 2010 at 6:32 PM, Brendan Eich <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> wrote:
>
>     On Sep 9, 2010, at 1:09 AM, Dmitry Soshnikov wrote:
>
>     > Thus the site's combined file won't be globally strict, however
>     since a lib is tested before a production release (at least I hope
>     so ;), then the lib's code should pass the strictness, and
>     therefore, a "use strict" may be even removed from the lib's file.
>     However, if not to remove, then an empty statement is enough.
>
>     That does not disable strict mode.
>
>
>
> Actually it does (since a strict mode, and the directive prologue is 
> an initial statement):
>
> "use strict";eval=10 // strict, error
>
> but
>
> ;"use strict";eval = 10; // non-strict, OK
>
> Oh, I see -- that solves the problem of strict mode in the second or 
> later parts of the concatenation.
>
> But the problem that's already come up on the web has strict mode 
> enabled in the first part, which complies with strict mode, but later 
> parts do not -- and there's no way to disable for them.
>
> OK, seems I didn't catch the goal then. I though, that there is some 
> single "js-holy-file", which is a combination of some 3rd-party 
> js-files (libs). And one (the first one) of the libs uses strict mode, 
> and other -- do not (that causes issues in the code of later parts, 
> 'cause the whole file becomes strict). But that exactly I proposed -- 
> to insert into the combined file an /empty statement/ _before_ the 
> first part. Thus, the whole single (combined) file will be non-strict. 
> Even if there are several strict directives later (from every part) -- 
> all of them (including the first one) will be canceled because of this 
> inserted empty statement at the beginning of the file.
>
> But repeat, there may be issues with different semantics of /this/ 
> value in strict and non-strict modes. So, as noted, it's just a 
> quick workaround.
>
> Also it won't help if a user uses dynamically loaded js-files from 
> external sources. So, this issue may really be the issue for users of 
> such external files.
>
> Dmitry.
>
>     /be
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100915/21efdcfc/attachment-0001.html>


More information about the es-discuss mailing list