Exactly what isaacs said. It doesn't provide a benefit outside of a handful of specific scenarios. It certainly doesn't increase performance and up until recently was harmful to performance. In return you will subtly change the functioning of existing code in ways that can be difficult to track down.
Certainly go ahead and use it for writing new stuff, but the idea of blanket applying it downright stupid and dangerous because it *will* often break code not specifically written with the differences in mind.
I feel omitting semicolons is hazardous as well, and as long as you aren't omitting them you won't run into this problem. I think optional semicolons are fine when a language is designed for it, but in JS they lead to ambiguities like this.
function foo() {} var foo = foo() foo ? bar() : etc()
The above is fine. But if you add an innocent paren the meaning of the program changes entirely:
function foo() {} var foo = foo() (foo) ? bar() : etc()
Anyway I've developed strict coding standards to avoid the pitfalls of semicolon insertion in JS, as I'm sure semicolon non-believers have had to do as well. It's just annoying because the way JS is designed, neither "never using semicolons" or "always using semicolons" is safe.
Hi Isaac, because of this octal impediment, we've decided to support 0o666 octal literals, and 0b10101 binary literals while we're at it, to ES6. However, in the meantime, I think this is a truly terrible reason to burden the community with the continued presence of non-strict server-side code. Think of non-strict code as toxic waste -- we can't deny its inevitable continued existence, but let's please keep it out of places where people are still living (active code being actively maintained). It isn't even lexically scoped. Going forward, its only remaining purpose should be to keep old websites working even when their sources are no longer being actively maintained, i.e., most of the web, but essentially none of NodeJS or other server-side code.
+1 to adding "use strict" to the module wrapper, so that all server side code is implicitly strict, whether it says so or not. Having uses of octal be a bit more awkward is a small price to pay for the increase in sanity.
On Fri, Jan 20, 2012 at 11:27 AM, Isaac Schlueter <i...@izs.me> wrote: > A while ago (0.5, I think?) I looked into adding a NODE_USE_STRICT > environment var that the module system could respond to, by putting > "use strict"; in the module wrapper.
> It didn't seem to affect any of our benchmarks. So, to claim speed > changes, we'll have to see proof.
> Attributing 99% of non-strict JS use to laziness is a bit > presumptuous. I don't use strict in my own code primarily because I > prefer my C-style languages to support octal literals.
> On Fri, Jan 20, 2012 at 11:11, AJ ONeal <coola...@gmail.com> wrote: > > There seem to be few primary reasons that people aren't using strict > mode:
> > 99% Laziness (the inefficient kind) > > 0.9% FUD - They're new to JavaScript or otherwise don't know about / > > understand it > > 0.09% They forget to type it out > > 0.009% They wan't to pretend to be cool using `with` > > 0.0001% They have a deep hatred for other living creatures and > purposefully > > and knowingly use `this` to access the global object
> > Since node is all about speed and "use strict"; mode allows for > significant > > performance enhancements, why doesn't it warn you when you forget or are > > lazy?
> > I'm watching one of the Crockford videos right now as and just aching > inside > > as I think of how many rookie mistakes make it in to npm that wouldn't > have > > a chance with a simple "use strict";
All the JavaScript in node-core gets linted. (We're not warning-free yet, we're getting closer.) We do not have octal literals in the node-core JavaScript. If you find any JavaScript in node that is not strict-compliant already, please send a patch. That is a bug, and would be highly surprising.
Past analysis (in node 0.5) showed that adding "use strict" made our benchmarks relevantly worse. If that changes, we'll start adding "use strict" in node's internal JavaScript. As long as the "toxic waste" is faster, we'll keep using it. Winning is more important than being right.
On Sat, Jan 21, 2012 at 12:44, Marcel Laverdet <mar...@laverdet.com> wrote: > The above is fine. But if you add an innocent paren the meaning of the > program changes entirely:
> function foo() {} > var foo = foo() > (foo) ? bar() : etc()
> Anyway I've developed strict coding standards to avoid the pitfalls of > semicolon insertion in JS, as I'm sure semicolon non-believers have had to > do as well. It's just annoying because the way JS is designed, neither > "never using semicolons" or "always using semicolons" is safe.
Marcel, you know full well that responsible semicolon minimalists would balk at the very notion of starting a line with ( and not prefixing it with a semicolon.
This "always" "never" business is a strawman duel. No one who knows what they're talking about endorses either.
> Anyway I've developed strict coding standards to avoid the pitfalls of semicolon insertion in JS, as I'm sure semicolon non-believers have had to do as well. It's just annoying because the way JS is designed, neither "never using semicolons" or "always using semicolons" is safe.
I always use semicolons where they belong, or at least, that is my intention. In what way is this not safe?
> +1 to adding "use strict" to the module wrapper, so that all server side > code is implicitly strict, whether it says so or not. Having uses of octal > be a bit more awkward is a small price to pay for the increase in sanity.
Would this also force REPL users to write strict JS?
> It certainly doesn't increase performance and up until recently was > harmful to performance.
This is a bit counter intuitive, but I suppose the checks that it forces adds a cost to performance. One way to deal with it is to turn it on during the development and may be remove it during the deployment (or in production). If there is a single configuration option with which this can be achieved then it is all the better.
> Certainly go ahead and use it for writing new stuff, but the idea of > blanket applying it downright stupid and dangerous because it *will* often > break code not specifically written with the differences in mind.
I can't imagine code breaking often for using 'use strict' in all use cases. Even if you can avoid it for now, isn't the JS language itself is going in that ( 'use strict') direction. Future versions will be far more less forgiving than the current.
> +1 to adding "use strict" to the module wrapper, so that all server side
code is implicitly strict, whether it says so or not. Having uses of octal be a bit more awkward is a small price to pay for the increase in sanity.
Bit surprised to hear this from you! It seems dangerous to introduce this.. Without "use strict" it's impossible to tell the toxic waste from otherwise, among other hazards.
@isaac
> Marcel, you know full well that responsible semicolon minimalists would
balk at the very notion of starting a line with ( and not prefixing it with a semicolon.
> This "always" "never" business is a strawman duel. No one who knows what
they're talking about endorses either.
Dude I wasn't trying to turn this into a duel. I'm saying that neither solution is ideal because of the way the language is designed. Instead of 1 great way to do things we have 2 mediocre ways to do things. Semicolonites and minimalists alike have to adhere to extra-grammatical rules in order to write properly functioning applications.
@ryan
> I always use semicolons where they belong, or at least, that is my
intention. In what way is this not safe?
For the most part you should be fine. The only thing I could realistically imagine biting you is the example above. function foo() { return 'foo';
On Fri, Jan 20, 2012 at 2:20 PM, Mark Miller <erig...@gmail.com> wrote: > Hi Isaac, because of this octal impediment, we've decided to support 0o666 > octal literals, and 0b10101 binary literals while we're at it, to ES6. > However, in the meantime, I think this is a truly terrible reason to burden > the community with the continued presence of non-strict server-side code. > Think of non-strict code as toxic waste -- we can't deny its inevitable > continued existence, but let's please keep it out of places where people > are still living (active code being actively maintained). It isn't even > lexically scoped. Going forward, its only remaining purpose should be to > keep old websites working even when their sources are no longer being > actively maintained, i.e., most of the web, but essentially none of NodeJS > or other server-side code.
> +1 to adding "use strict" to the module wrapper, so that all server side > code is implicitly strict, whether it says so or not. Having uses of octal > be a bit more awkward is a small price to pay for the increase in sanity.
> On Fri, Jan 20, 2012 at 11:27 AM, Isaac Schlueter <i...@izs.me> wrote:
>> A while ago (0.5, I think?) I looked into adding a NODE_USE_STRICT >> environment var that the module system could respond to, by putting >> "use strict"; in the module wrapper.
>> It didn't seem to affect any of our benchmarks. So, to claim speed >> changes, we'll have to see proof.
>> Attributing 99% of non-strict JS use to laziness is a bit >> presumptuous. I don't use strict in my own code primarily because I >> prefer my C-style languages to support octal literals.
>> On Fri, Jan 20, 2012 at 11:11, AJ ONeal <coola...@gmail.com> wrote: >> > There seem to be few primary reasons that people aren't using strict >> mode:
>> > 99% Laziness (the inefficient kind) >> > 0.9% FUD - They're new to JavaScript or otherwise don't know about / >> > understand it >> > 0.09% They forget to type it out >> > 0.009% They wan't to pretend to be cool using `with` >> > 0.0001% They have a deep hatred for other living creatures and >> purposefully >> > and knowingly use `this` to access the global object
>> > Since node is all about speed and "use strict"; mode allows for >> significant >> > performance enhancements, why doesn't it warn you when you forget or are >> > lazy?
>> > I'm watching one of the Crockford videos right now as and just aching >> inside >> > as I think of how many rookie mistakes make it in to npm that wouldn't >> have >> > a chance with a simple "use strict";
What about a "stricter" option to get a warning or error whenever the
compiler automatically inserts a semi-colon. Looks like this would
make things safe for "semicolonites".
With:
return
foo;
you would get a warning about a semicolon being added at the end of
the return line.
But with:
return foo;
you would not get any warning.
Should not be too difficult to hack into a preprocessor.
Bruno
On Jan 22, 9:46 am, Marcel Laverdet <mar...@laverdet.com> wrote:
> @mark> +1 to adding "use strict" to the module wrapper, so that all server side
> code is implicitly strict, whether it says so or not. Having uses of octal
> be a bit more awkward is a small price to pay for the increase in sanity.
> Bit surprised to hear this from you! It seems dangerous to introduce this..
> Without "use strict" it's impossible to tell the toxic waste from
> otherwise, among other hazards.
> @isaac> Marcel, you know full well that responsible semicolon minimalists would
> balk at the very notion of starting a line with ( and not prefixing it with
> a semicolon.
> > This "always" "never" business is a strawman duel. No one who knows what
> they're talking about endorses either.
> Dude I wasn't trying to turn this into a duel. I'm saying that neither
> solution is ideal because of the way the language is designed. Instead of 1
> great way to do things we have 2 mediocre ways to do things. Semicolonites
> and minimalists alike have to adhere to extra-grammatical rules in order to
> write properly functioning applications.
> @ryan> I always use semicolons where they belong, or at least, that is my
> intention. In what way is this not safe?
> For the most part you should be fine. The only thing I could realistically
> imagine biting you is the example above.
> function foo() {
> return
> 'foo';
> }
> foo() returns undefined!
> On Fri, Jan 20, 2012 at 2:20 PM, Mark Miller <erig...@gmail.com> wrote:
> > Hi Isaac, because of this octal impediment, we've decided to support 0o666
> > octal literals, and 0b10101 binary literals while we're at it, to ES6.
> > However, in the meantime, I think this is a truly terrible reason to burden
> > the community with the continued presence of non-strict server-side code.
> > Think of non-strict code as toxic waste -- we can't deny its inevitable
> > continued existence, but let's please keep it out of places where people
> > are still living (active code being actively maintained). It isn't even
> > lexically scoped. Going forward, its only remaining purpose should be to
> > keep old websites working even when their sources are no longer being
> > actively maintained, i.e., most of the web, but essentially none of NodeJS
> > or other server-side code.
> > +1 to adding "use strict" to the module wrapper, so that all server side
> > code is implicitly strict, whether it says so or not. Having uses of octal
> > be a bit more awkward is a small price to pay for the increase in sanity.
> > On Fri, Jan 20, 2012 at 11:27 AM, Isaac Schlueter <i...@izs.me> wrote:
> >> A while ago (0.5, I think?) I looked into adding a NODE_USE_STRICT
> >> environment var that the module system could respond to, by putting
> >> "use strict"; in the module wrapper.
> >> It didn't seem to affect any of our benchmarks. So, to claim speed
> >> changes, we'll have to see proof.
> >> Attributing 99% of non-strict JS use to laziness is a bit
> >> presumptuous. I don't use strict in my own code primarily because I
> >> prefer my C-style languages to support octal literals.
> >> On Fri, Jan 20, 2012 at 11:11, AJ ONeal <coola...@gmail.com> wrote:
> >> > There seem to be few primary reasons that people aren't using strict
> >> mode:
> >> > 99% Laziness (the inefficient kind)
> >> > 0.9% FUD - They're new to JavaScript or otherwise don't know about /
> >> > understand it
> >> > 0.09% They forget to type it out
> >> > 0.009% They wan't to pretend to be cool using `with`
> >> > 0.0001% They have a deep hatred for other living creatures and
> >> purposefully
> >> > and knowingly use `this` to access the global object
> >> > Since node is all about speed and "use strict"; mode allows for
> >> significant
> >> > performance enhancements, why doesn't it warn you when you forget or are
> >> > lazy?
> >> > I'm watching one of the Crockford videos right now as and just aching
> >> inside
> >> > as I think of how many rookie mistakes make it in to npm that wouldn't
> >> have
> >> > a chance with a simple "use strict";
On Sun, Jan 22, 2012 at 1:27 AM, Seva Adari <oddiss...@gmail.com> wrote: > It certainly doesn't increase performance and up until recently was >> harmful to performance.
> This is a bit counter intuitive, but I suppose the checks that it forces > adds a cost to performance.
That's not it at all. When designing strict mode, we were very careful to ensure that any effect it had on performance would be positive. For an optimizing engine like v8, strict vs non-strict won't have much of a speed advantage, as most potential gains have already been achieved by harder analysis. But with the comparable engineering effort, there should certainly be no penalty for using strict.
Rather, the issue is "comparable enginerring effort". I just verified with one of the v8 people that problem is that none of the benchmarks say "use strict";. To get this situation repaired, I suggest that someone in the Node community should release, for example, "NodeSpider", a variant of SunSpider in which all the tests are run in strict mode. In addition, if you capture the particular cases that are causing node code to slow down and turn these into further NodeSpider tests, that would be great. If NodeSpider gets any prominence at all, any remaining penalty for strict mode would disappear quickly, and strict mode may even start to realize some advantages. The v8 team likes to drive their optimizations efforts by things they can measure.
> One way to deal with it is to turn it on during the development and may be > remove it during the deployment (or in production). If there is a single > configuration option with which this can be achieved then it is all the > better.
That would be an improvement on the status quo. But it reminds me of a comment by Tony Hoare about array bounds checking. Many people at the time wanted to have array bounds checking turned on during development to help catch bugs, but then turn it off in deployment for extra speed. Hoare described this as[1] "Like turning off all the safety devices on an airplane just before it is about to start carrying passengers".
[1] Paraphrasing, since I can't find it. If anyone knows the exact post or where to find it, please let me know. Thanks.
>> Certainly go ahead and use it for writing new stuff, but the idea of >> blanket applying it downright stupid and dangerous because it *will* often >> break code not specifically written with the differences in mind.
Because the browser has to remain compatible with a universe of legacy no one can change, we have no choice there. For node, any code that doesn't work in strict should already be considered broken. Going forward, no one new to JavaScript should ever be taught the non-strict language. And even today, very few who think they understand JavaScript really even understand the non-strict language. The illusion of understanding is mostly due to ignorance of the odd corners.
> I can't imagine code breaking often for using 'use strict' in all use > cases. Even if you can avoid it for now, isn't the JS language itself is > going in that ( 'use strict') direction. Future versions will be far more > less forgiving than the current.
It is indeed. But for the sake of maintaining backward compatibility with ES5-strict, future versions will likely be no more nor less forgiving that current strict mode is.
On Sun, Jan 22, 2012 at 3:46 AM, Marcel Laverdet <mar...@laverdet.com>wrote:
> @mark > > +1 to adding "use strict" to the module wrapper, so that all server > side code is implicitly strict, whether it says so or not. Having uses of > octal be a bit more awkward is a small price to pay for the increase in > sanity.
> Bit surprised to hear this from you! It seems dangerous to introduce > this.. Without "use strict" it's impossible to tell the toxic waste from > otherwise, among other hazards.
I suppose another possibility would be to reject all code that doesn't begin with "use strict";, but I expect this wouldn't go over well.
Node is a new platform. It isn't a browser. It can define what variant of JS it accepts. I see little reason for node to continue to support ES5-non-strict and much reason not to.
node.js does not have an opinion about the JavaScript language.
never has. never will.
That includes strict mode, and ES.next features in case anyone was wondering.
node.js takes v8 "vanilla", no changes, no tweaks. If v8 doesn't warn w/o strict mode, neither does node.js.
This is less a technology decision and more of a community/focus decision. We succeed by limiting the surface area of the problem we are trying to solve and the language isn't part of that.
If you want node.js to warn on strict, tell the v8 people :)
-Mikeal
On Jan 22, 2012, at January 22, 20127:48 AM, Mark Miller wrote:
> On Sun, Jan 22, 2012 at 3:46 AM, Marcel Laverdet <mar...@laverdet.com> wrote: > @mark > > +1 to adding "use strict" to the module wrapper, so that all server side code is implicitly strict, whether it says so or not. Having uses of octal be a bit more awkward is a small price to pay for the increase in sanity.
> Bit surprised to hear this from you! It seems dangerous to introduce this.. Without "use strict" it's impossible to tell the toxic waste from otherwise, among other hazards.
> I suppose another possibility would be to reject all code that doesn't begin with "use strict";, but I expect this wouldn't go over well.
> Node is a new platform. It isn't a browser. It can define what variant of JS it accepts. I see little reason for node to continue to support ES5-non-strict and much reason not to.
> node.js does not have an opinion about the JavaScript language.
> never has. never will.
> That includes strict mode, and ES.next features in case anyone was wondering.
> node.js takes v8 "vanilla", no changes, no tweaks. If v8 doesn't warn w/o strict mode, neither does node.js.
> This is less a technology decision and more of a community/focus decision. We succeed by limiting the surface area of the problem we are trying to solve and the language isn't part of that.
> If you want node.js to warn on strict, tell the v8 people :)
> -Mikeal
> On Jan 22, 2012, at January 22, 20127:48 AM, Mark Miller wrote:
>> On Sun, Jan 22, 2012 at 3:46 AM, Marcel Laverdet <mar...@laverdet.com> wrote: >> @mark >> > +1 to adding "use strict" to the module wrapper, so that all server side code is implicitly strict, whether it says so or not. Having uses of octal be a bit more awkward is a small price to pay for the increase in sanity.
>> Bit surprised to hear this from you! It seems dangerous to introduce this.. Without "use strict" it's impossible to tell the toxic waste from otherwise, among other hazards.
>> I suppose another possibility would be to reject all code that doesn't begin with "use strict";, but I expect this wouldn't go over well.
>> Node is a new platform. It isn't a browser. It can define what variant of JS it accepts. I see little reason for node to continue to support ES5-non-strict and much reason not to.
On Sun, Jan 22, 2012 at 10:38, Dick Hardt <dick.ha...@gmail.com> wrote: > If you want node.js to warn on strict, tell the v8 people :)
I wouldn't be opposed to an env/cmdline/compile-time flag to make Node add "use strict" to all modules it loads. But it'd have to be clean, and introduce no other hazards, or break anything that already works. And if it's not demonstrably faster, it won't be the default.
>> I always use semicolons where they belong, or at least, that is my intention. In what way is this not safe?
> For the most part you should be fine. The only thing I could realistically imagine biting you is the example above. > function foo() { > return > 'foo'; > }
> foo() returns undefined!
Of course it does. I wouldn't expect it to do anything different. :)
It would also never occur to me to write the above code. If I wanted to return 'foo' I would write:
I'm not saying that, if there is absolutely no possible way to work around the flaws inherent in the system, that you should not get the work done.
Rather, what I'm saying is that you should adhere to the rules first and cater to the exceptions on a case by case basis.
I realize that test-driven development kind of trains your brain to consider every possible edge-case (and a lot of people have that pre-optimization mentality anyway), but...
*This is a 90 / 10 problem.* ===
What percentage of NodeJS developers use Octal? What percentage of JavaScript *users* use Octal?
What percentage of JavaScript *users* don't realize that if they forget `var` their variable becomes a global?
The question here isn't about the 1% that use these features, it's about 80% that get tripped up by simple newbie mistakes.
*With more power comes more responsibility* ===
I would rather cause disciplined devs like you and me a little grief here and there than every single newbie that comes into JavaScript and NodeJS suffer completely unintuitive silent errors and such.
If Octal is so important for the NodeJS devs, then add a core module for the basic operations. But what about the users?
*It's about the user* ===
Do you see what I'm saying? *Application languages* - JavaScript, ruby, python, etc - *are about abstraction. That is their purpose!*
Not wanting workarounds isn't "lazy". I'm pretty sure that if you have
> to replace well-written stuff that just works with "workarounds", this > is a huge -1 on that change.
If it were well-written, it shouldn't have any issues in strict mode other than the octal change.
> > (function () { > > "use strict";
> Without the indent. Please.
I'm okay with that. It just looks weird without the indent to me. If I had seen some sort of precedent without the indent, I would have used it that way.
> Globals are EVIL. BAD. RUDE. INCONSIDERATE. NASTY.
> > I can't believe I'm hearing support for globals!!
> I think you're exaggerating a lot here. What about, for example, > "process"? Or what about logging?
I wish so bad that it were required instead.
It has caused me extra work (albeit minimal) to get some node / npm modules to run in the browser because `process` is used.
> > I'm being sincere. I thought that everyone in the programming communities > > had gotten the memo that globals and gotos are words you feel dirty > inside > > for using (except in the kernel where you use gotos to implement the > > decorator pattern without the overhead of function calls - and the people > > there are hopefully disciplined enough to not make severe design > mistakes).
> Uh? So you're basically saying "globals aren't too bad, but they're > sharp tools that can be used for nasty stuff, so drop them and use > this wooden knife instead"? Yes, it sometimes is bad to use them, and > yes, it's not what we should put on top of tutorials, but we > definitely shouldn't discourage them that much.
I was saying that `goto` takes the place of the decorator pattern in C, since C is a hardware language with a limited feature set, not an application language with wonderful abstractions.
The kernel isn't an application. It has a different set of design patterns than applications do.
Applications should not use globals.
> > Browser > > --- > > You don't need globals either. A TON of effort has gone in to making sure > > that you can write modular JavaScript. Thanks to RequireJS, Pakmanager, > and > > Ender, you can install straight from npm into packed browser-safe code.
> What about JSONP? You need global functions for that, no?
Actually, for all modern browsers (including MSIE), JSONP is no longer necessary. Welcome CORS and XHR2. :-D
I'm not saying that, if there is absolutely no possible way to work around the flaws inherent in the system, that you should not get the work done, but that you should adhere to the rule first and cater to the exceptions on a case by case basis.
(And actually, I've been considering writing a `window` module for the browser that copies the properties that are actually part of `window`)
> > Octals > > --- > > I guess since a lot of people on this list work with c++ for native node > > modules it makes sense.
> Uh... and e.g. working with the filesystem, too.
> > But JavaScript is a high-level language primarily used for interacting > with > > users. > > If you want to use octals... USE C!
> Ah, right, Javascript doesn't belong on the server or so. You're sooo > right.</scnr>
JavaScript is an application laguage. It works just as well on the server as ruby or python - just a bit better because it handles JSON natively and has a built-in event system.
> > Do you know how many times I've been bitten by parsing user input that > had a > > leading '0' and have scratched my head for too long trying to figure out > > where the math had gone wrong? A lot! (but I'm getting better and > > remembering to check for corner cases that strict mode can't protect me > > from);
> Well then, sounds like you're using the wrong tools to parse user > input. And like you're not reading documentation. E.g. parseInt only > tries to determine the radix based on the input if you don't > explicitely specify it.
That's exactly my point. I *want* an application language to hold my hand a little (or at least be intuitive - there should be a parseOct and parseHex - or do you have an argument or using a radix of 3 and 7 as well?).
If I wanted to have absolute full control I'd use C.
> In return you will subtly change the functioning of existing code in ways > that can be difficult to track down.
I don't believe so. All of the changes to strict mode throw errors.
this = null -- throws an error using octal -- throws an error not declaring a variable -- throws an error using with -- throws an error
in which case would the problem be subtle?
Exactly what isaacs said. It doesn't provide a benefit outside of a handful
> of specific scenarios. It certainly doesn't increase performance and up > until recently was harmful to performance.
Those handful of scenarios are the things that newbies trip up on most (I remember being a newbie, do you?)
I'm part of the training process new hires, some of which are new to JS. There's a reason that strict mode exists. It IS to help.
Youth and Beauty ===
I'm not saying to enable strict mode by default, I'm saying to add a warning when it isn't used in the app which is being run. (perhaps not when included with `require`, that would be annoying).
I don't believe that The changes to strict mode throw errors
Node is so young. So many newbies are getting interested in JavaScript because of Node.
Let Node be a force of positive change.
Speed ===
Just as with binary arrays, strict mode won't gain the speed improvements until the implementation is complete (there are still a few things lacking in v8 last time I explicitly tested).
But as sure as Google wants v8 to be the fastest engine, the optimizations will come, just as they have with binary arrays.
> On Sun, Jan 22, 2012 at 10:38, Dick Hardt <dick.ha...@gmail.com> wrote: >> If you want node.js to warn on strict, tell the v8 people :)
> I wouldn't be opposed to an env/cmdline/compile-time flag to make Node > add "use strict" to all modules it loads. But it'd have to be clean, > and introduce no other hazards, or break anything that already works. > And if it's not demonstrably faster, it won't be the default.
node's lib/* files are pre-compiled so if we want this to pertain to lib/* files it'll have to be a compile time flag.
i'm opposed to compile flags that change the behavior of node, especially in ways that you can't determine by just checking the version.
On Sun, Jan 22, 2012 at 11:08 PM, AJ ONeal <coola...@gmail.com> wrote: > In return you will subtly change the functioning of existing code in ways >> that can be difficult to track down.
> I don't believe so. All of the changes to strict mode throw errors.
> this = null -- throws an error > using octal -- throws an error > not declaring a variable -- throws an error > using with -- throws an error
> in which case would the problem be subtle?
The following actually happened to a friend of mine. A brilliant Smalltalk programmer who has done many impressive things, but had not yet immersed himself in JavaScript arcana for years. In order to use various primitives in a more object-like way, he added (among other things) the following method:
> The following actually happened to a friend of mine. A brilliant Smalltalk > programmer who has done many impressive things, but had not yet immersed > himself in JavaScript arcana for years. In order to use various primitives > in a more object-like way, he added (among other things) the following > method:
> or if this code occurs in a strict context, solves the problem. No nasty > hidden coercion surprise.
Interesting. That's just weird.
> How about
> function foo(str) { > var x = 8; > eval(str); > return function bar() { return x; }; > }
> When bar is later called, what x variable does it read?
> For both of these, the difference is not an easy to diagnose error. It is > silent confusion.
Okay, interesting point made. I suppose which is expected would depend on what you would expect.
Intuitively I would expect that `str` executes in it's own context and that `x` would always return 8. So in not-strict mode perhaps it's possible to access `x` in `str`?
On Mon, Jan 23, 2012 at 12:09 AM, AJ ONeal <coola...@gmail.com> wrote: > The following actually happened to a friend of mine. A brilliant Smalltalk >> programmer who has done many impressive things, but had not yet immersed >> himself in JavaScript arcana for years. In order to use various primitives >> in a more object-like way, he added (among other things) the following >> method:
>> or if this code occurs in a strict context, solves the problem. No nasty >> hidden coercion surprise.
> Interesting. That's just weird.
Which behavior do you find weird:
false.not() ==> false or false.not() ==> true ?
If (as I hope) you find the first weird and surprising and would have expected the second, it supports my case that even most experienced JS programmers do not really understand non-strict mode. It is filled with subtle minefields which most programs survive mostly by accident.
>> function foo(str) { >> var x = 8; >> eval(str); >> return function bar() { return x; }; >> }
>> When bar is later called, what x variable does it read?
>> For both of these, the difference is not an easy to diagnose error. It is >> silent confusion.
> Okay, interesting point made. > I suppose which is expected would depend on what you would expect.
> Intuitively I would expect that `str` executes in it's own context and > that `x` would always return 8. > So in not-strict mode perhaps it's possible to access `x` in `str`?
Actually, in both strict and non-strict mode, str can access the 'x' variable shown here, since the eval "call" shown here is a "direct eval", which is really a special form rather than a function call. However, in trying to clarify, I realize that my example was flawed. The following code correctly raises the riddle I was trying to raise above:
function makeFoo() { var x = 8; function foo(str) { eval(str); return function bar() { return x; }; } }
Again, in both strict and non-strict mode, str can access (both read and write) the 'x' variable shown here, since the eval "call" shown here is a "direct eval", which is really a special form rather than a function call. So the question is not "What value does bar() return?", which could be any value that str decides to store into the above "x" variable. The riddle is "What x variable does bar() read?".
Once you know the answer, if you find that answer surprising, this further supports my case. Although the strict language is still tricky, the non-strict language is hopeless. Almost no one who programs in it actually understands it.
In getting Narcissus to work in Node I had to change chunks of it to use strict because V8's --harmony won't let you use `let` outside of strict mode. When I did this it caused errors that I traced back to Narcissus's use of const in eval. Instead of defining the consts in the local function scope, they were defined globally. After finally tracking down the cause I had to wrap the code such that the eval was done in a non-strict wrapper function.
> Globals are EVIL. BAD. RUDE. INCONSIDERATE. NASTY.
> I can't believe I'm hearing support for globals!!
> Seriously, that blows my mind.
> I'm being sincere. I thought that everyone in the programming communities > had gotten the memo that globals and gotos are words you feel dirty inside > for using (except in the kernel where you use gotos to implement the > decorator pattern without the overhead of function calls - and the people > there are hopefully disciplined enough to not make severe design mistakes).
This is mostly tangential, but usually indirect global references are used when wanting to interact with host objects or natives, maybe not necessarily to create globals. For some reason I can't think of any off the top of my head, so obviously it's not THAT common, but I recall having seen it multiple times in respected modules. Again, off the top of my head I THINK it's usually used in the case of pollyfills, which are language specific, environment agnostic and global in nature where the implementation does not care about the name of the global object (window?) so much as merely obtaining a reference to it.
Again though, if you've never encountered this issue, it's probably of little concern to you. =)
Cheers, Adam Crabtree
-- Better a little with righteousness than much gain with injustice. Proverbs 16:8
In short, it's deprecated to remove incidental granting of permission to execute a function by passing its arguments object. This requires that API consumers must now explicitly name and pass the function instead.
While I understand the security implications and reasoning for this, it makes for a far uglier API for consumers. So in lieu of a more compelling incentive than protection from yourself (globals) and the merit badge of using strict mode, I don't see this as either FUD or laziness, but merely a complication with a currently insufficient value proposition that will necessarily and unavoidably break various APIs.
