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: [email protected] [mailto:es-discuss- > > [email protected] (mailto:[email protected])] 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 > > [email protected] (mailto:[email protected]) > > https://mail.mozilla.org/listinfo/es-discuss > > > > > _______________________________________________ > es-discuss mailing list > [email protected] (mailto:[email protected]) > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
