"by default" as if it's there there must be a reason since, as Oliver pointed, is changing program behavior once removed.
I would expect closure compiler to be smart enough to understand strictness and dafine it once in the most outer scope or grouping them but actually with gzip this is not such big problem. Said that, I would rather force removal of "use strict" 'cause if there is explicit desire from the developer. Isn't it? On Thu, Nov 15, 2012 at 2:58 PM, ๏̯͡๏ Jasvir Nagra <j...@nagras.com> wrote: > > > Jasvir Nagra > > > > On Thu, Nov 15, 2012 at 1:43 PM, Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> have to dig about the Engines problems, I assumed it was a matter of >> "hey, I am your parent caller" pointer and nothing else. >> >> Said that, you want a use case, here: >> https://github.com/WebReflection/poo/blob/master/src/superable.js >> >> This let you make any object superable so that you can access >> this.super() as it is specified in ES6 (without this. but that's not >> convenient to pollute the global scope with a "super" getter and without a >> context) without impacting performance at all unless the method is >> accessing that super. In latter case yes, you have a performance impact and >> it's going to be probably slower than other solutions but it's about having >> everything else at the same speed except when you do need super access and >> not every time you call a method. >> >> More over, you don't need a central uniq entry point to share superable >> so that different libraries could extend each other without problems. >> >> This is not possible if the code is under use strict directive, this is >> why I had to update also require_client to force all code to be evaluated >> without that directive once minified: >> https://github.com/WebReflection/require_client >> >> About minifiers, Google Closure compiler and YUI are only two examples >> ... do you know anyone better than these two that by default does not >> change the "use strict" behavior? That would be nice to know, thanks. >> > > I am not sure why "by default" matters. Closure compiler takes a flag > --language_in=ECMASCRIPT5_STRICT and preserves strictness. > > br >> >> >> On Thu, Nov 15, 2012 at 1:16 PM, David Herman <dher...@mozilla.com>wrote: >> >>> On Nov 15, 2012, at 1:15 PM, David Herman <dher...@mozilla.com> wrote: >>> >>> > On Nov 15, 2012, at 1:04 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> >>> wrote: >>> > >>> >> On Nov 15, 2012, at 12:37 PM, Andrea Giammarchi wrote: >>> >> >>> >>> I believe with is much more problematic than caller for all Engines >>> out there. A reference to "who is invoking" cannot be that bad ... is it? >>> >> >>> >> Yes it is! It is a capability leak. It give a callee access to >>> functions that would otherwise be inaccessible to the callee. Who knows >>> what mischief can be accomplished by calling such functions. >>> > >>> > What's more, it's totally inadequate as a stack walking tool. If any >>> function appears twice in a call stack (most commonly in the presence of >>> recursion), you can't walk the whole stack. You either have to detect the >>> repeat and give up, or loop infinitely. So in addition to being a security, >>> performance, and engineering nightmare, arguments.caller is pretty much >>> useless. >>> >>> And to be clear, it *is* a problem for engines: it prevents proper tail >>> calls (or even tail call optimization). >>> >>> Dave >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
