On Thu, Dec 18, 2014 at 8:50 AM, Caitlin Potter <caitpotter88 at gmail.com>
wrote:
>
>
>
> On Dec 18, 2014, at 10:54 AM, Mark S. Miller <erights at google.com> wrote:
>
>
>
> On Thu, Dec 18, 2014 at 4:46 AM, Alex Kocharin <alex at kocharin.ru> wrote:
>>
>>
>>
>> 16.12.2014, 17:04, "Andrea Giammarchi" <andrea.giammarchi at gmail.com>:
>>
>>
>>
>> On Tue, Dec 16, 2014 at 1:50 PM, Felipe Nascimento de Moura <
>> felipenmoura at gmail.com> wrote:
>>
>>
>> function () {
>>     use strict, safe;
>> }
>>
>> This could allow us to even add some extra scoped-options, such as a safe
>> mode..
>>
>>
>>
>> I'm quite sure we've discussed already other directives and the unanimous
>> answer here was "NO, 'use strict' is already problematic"
>>
>>
>>
>> It's problematic mostly because it can't be turned off when it's needed.
>>
>
> When is this needed?
>
>
> It would be nice for testing (engines and applications), at any rate.
>
> If you have similar behaviour for strict and non-strict modes:
>
> ```
> [true, false].forEach(function someUnitTest(scopeMode) {
>   Reflect.setStrictMode(scopeMode);
>
>   assertEquals(“quantum puppies”, doTheThing());
> });
> ```
>
> vs
>
> ```
> (function someUnitTestStrictMode() {
>   “use strict”;
>   assertEquals(“quantum puppies”, doTheThing());
> })();
>
> (function someUnitTestSlappyMode() {
>   assertEquals(“quantum puppies”, doTheThing());
> })();
> ```
>
>
>
>> So another directive like "use nostrict" would be welcome imho.
>> Especially in modules when "strict" is on by default.
>>
>
>
>     //... strict context
>     (1,eval)("...sloppy code...");
>     //... strict context
>
>
> eval has other implications, so it doesn’t always accomplish what you want
> :(
>

It's good enough for these tests.



> Plus, the contents are a lot harder to read in most text editors ;)
>


(1,eval)("" + function(){...strict code you want to execute sloppy...})()


The code in the function is actually strict code, and your editor will
treat it as such. However,
Function.prototype.toString.call(user-written-function) will result in
function source that, when evaled in a sufficiently similar lexical
context, will yield a function with the same [[Call]] behavior. In this
case, we're violating the spec precondition by evaling it in a context
that's sloppy rather than strict. Practically, this does what you want.


>
>
>>
>> I think we should either deprecate one of the modes, or officially
>> support multiple modes and provide a method to switch between them.
>>
>
> Feel free to consider sloppy mode deprecated. I do.
>
>
> Well sure, but unfortunately it’s not going to just disappear :(
>

See how much good deprecating it did?


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141218/170bec5c/attachment.html>

On Thu, Dec 18, 2014 at 8:50 AM, Caitlin Potter <caitpotter88 at gmail.com> wrote:

> eval has other implications, so it doesn’t always accomplish what you want
> :(

It's good enough for these tests.



> Plus, the contents are a lot harder to read in most text editors ;)

```js
(1,eval)("" + function(){...strict code you want to execute sloppy...})()
```


The code in the function is actually strict code, and your editor will
treat it as such. However,
Function.prototype.toString.call(user-written-function) will result in
function source that, when evaled in a sufficiently similar lexical
context, will yield a function with the same [[Call]] behavior. In this
case, we're violating the spec precondition by evaling it in a context
that's sloppy rather than strict. Practically, this does what you want.

> Well sure, but unfortunately it’s not going to just disappear :(

See how much good deprecating it did?