What would a 1JS-friendly strict mode look like?
Interesting question! I always found it weird, myself!
function () {
"use strict";
}
It might be a new token, perhaps?
function () {
use strict, safe;
}
This could allow us to even add some extra scoped-options, such as a safe mode...I am pretty sure you guys would have even more options in mind, either to constrain, or to liberate access or features! An interesting example for that use, would be the way browsers are implementing the use of es6 and the way you enable it in each browser! We could use something like (for the future features, as well):
function () {
use strict, experimental; // allows the use of experimental features
}
function () {
use strict, unstable; // allows the use of features that are soon going to be official
}
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"
1JS strict mode would look like modules.
That makes sense, yes. It’s great that we get this chance to clean up things in ECMAScript 6.
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20141218/5f8a2f19/attachment
Wouldn't it be interesting to have a "scope" variable? as is arguments...
Something like
function(){
window.scope.set('strict', true);
}
of
function(){
scope.set({
"strict": true,
"experimental": true,
"safe": false
});
// then, other functions could turn on/off some of it
someEl.addEventListener('click', function(){
scope.set('safe', true);
...
// or even
if( scope.get('experimental') ){
// doSomethingNew();
}
});
}
This is just a "raw" suggestion, and personally, I think it should NOT be possible to turn off an "strict" or "safe" definition, even when it comes from a parenting scope. But this way, it would be "polyfillable", future-friendly, for new stuff and new versions of ES, and browser support, and maybe the new scope feature might bring some other benefits, such as a native "supports" for new feature, or a new way to support sandboxed scopes.
I wonder if something like this couldn't be used to define a scope as a "worker", to run in a new process thread(sandboxed, in this case).
Let me know what you think, or if you haven't already discussed something similar.
On Thu, Dec 18, 2014 at 4:46 AM, Alex Kocharin <alex at kocharin.ru> wrote:
It's problematic mostly because it can't be turned off when it's needed.
When is this needed?
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
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.
On Dec 18, 2014, at 10:54 AM, Mark S. Miller <erights at google.com> wrote:
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 :( Plus, the contents are a lot harder to read in most text editors ;)
Feel free to consider sloppy mode deprecated. I do.
Well sure, but unfortunately it’s not going to just disappear :(
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 ;)
(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?
On Thu, Dec 18, 2014 at 6:01 PM, Mark S. Miller <erights at google.com> wrote:
(1,eval)("" + function(){...strict code you want to execute sloppy...})()
This doesn't work in SpiderMonkey: stringifying functions retains their
strictness, no matter where strict mode is activated. In this case, the
result would be the string function (){\n"use strict";\n...strict code you want to execute sloppy...}
It's unfortunate that this doesn't behave the same in all engines, but I would argue that SpiderMonkey's stringification is the more faithful one.
I didn't know that SpiderMonkey did that, but I agree it is better. In light of this news, I'm glad my code sample doesn't work ;).
As for "would be good for all engines to act the same", the precondition was carefully crafted so that engines did not need to retain the original source, but rather, just enough for behavioral equivalence. Nevertheless, if we could get everyone to agree on SpiderMonkey's behavior here, it would be better. Too late for ES6 though.
SpiderMonkey does retain the original source. However, it adds the "use strict" if the function is defined in a strict-mode scope. Reading the rules for Function.prototype.toString, it's clear that not doing that is valid, as the spec only requires behavioral equivalence "if the string is evaluated, using eval in a lexical context that is equivalent to the lexical context".
So yes, it would be nice to get agreement here, but it's not as important as I first thought.
did anyone see my suggestion? (actually, am not sure my e-mails are going out!)
Personally(again, my opinion), I think it is at least weird, having a "floating string" on your code! Specially because(by now) this is the only situation, with only one option, what makes it an "exception". ES has so many great patterns, the least exceptions for the rules, the better! That's why I thought about a "scope" token/accessor. Besides that, some advantages such as enabling experimental features or not, safe mode, etc. When I think about it, new ideas come! Let's say you may use:
scope.set("debug", ["error", "call");
and this would cause any function call inside this scope, to stop(if a console is opened) pausing the flow for debugging, or also, when any error occur inside it. Other things could be done to log calls, as well(changing the verbosity of the scope).
Sorry if this idea is stupid and I can't see it! hehe
Strict mode is a static, compile-time setting, not something that can be modified at runtime. Hence, your suggestion falls short, because it would be a runtime setting.
the reason why a "floating string" was used is to not introduce syntax that
older engines would trip over. Something like use strict (without the
quotes) would cause that. You might say that scope.set would only be
allowed at compile time or something, but that would be problematic both
because it's not backwards-compatible (what if code uses a collection
called "scope"?) and because it's not distinguishable from normal code.
Also, "use strict" has been around for years and nothing will ever get it removed/replaced, anymore.
ok, makes sense!
The fact that this works at the compile time, really makes it impossible to modify from scope to scope! It was just a suggestion, syntax or the way it could be implemented was not supposed to be exactly like that...but I think it might be interesting if we had some of the advantages/possibilities mentioned, like safe mode, debug or (specially)experimental...or the supports for new features in the future. My concern here, is about future evolution on languages, browsers and implementation.
It could be a string like "use strict, experimental"...could even be an annotated comment.
Anyways, I believe it might be something useful to think about :)
Till Schneidereit wrote:
So yes, it would be nice to get agreement here, but it's not as important as I first thought.
File a bug at bugs.ecmascript.org and let's see where that goes!
AK> I think we should either deprecate one of the modes, or officially support multiple modes and provide a method to switch between them.
MM> Feel free to consider sloppy mode deprecated. I do.
CP> Well sure, but unfortunately it’s not going to just disappear :(
MM> See how much good deprecating it did?
...and, scene.
If I had a nickel for every time a conversation about web standards went exactly like this, I would be All Set For Lunch. For weeks.
:)
Can you even deprecate sloppy mode? I know dev tools often use it to inject the dev console extension APIs safely
On Fri, Dec 19, 2014 at 9:08 AM, Bradley Meck <bradley.meck at gmail.com>
wrote:
Can you even deprecate sloppy mode?
If you mean, can we get rid of it? Then no.
If you mean, can we discourage people from using it, and sneer at the people who still do? Then yes.
Otherwise, please clarify what you mean by the question. Thanks.
I know dev tools often use it to inject the dev console extension APIs safely
Why do they need sloppy mode for this?
Given 1JS – would strict mode have been done differently in hindsight? How?