"no strict"; directive

Oliver Hunt oliver at apple.com
Thu Nov 15 12:57:06 PST 2012


Strict mode has substantial semantic impact, any minifier that is removing it is changing program behaviour, potentially dramatically.  If you're okay with the minifier disabling strict mode you should not be developing with strict mode at all, as it will mean your development builds will potentially have different behaviour from what you're deploying, as an argument for "no strict", this makes no sense.

And yes adding an additional closure and call to every function is going to adversely impact performance, but why are you doing that in the first place?  If you're using .caller for debugging it's unnecessary in production, so the performance hit won't be there when it matters.

So far you haven't given any real use-case where arguments.caller is a) better than the built in functionality, and b) actually necessary in production builds.

--Oliver

On Nov 15, 2012, at 12:45 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

> function wrappers created to simulate caller are obviously slower. 2 calls, the wrap and the wrapped, 1 extra nested scope, and 2 callers, since these will run no strict in any case. A de-coupled entry point to reach a caller could easily speed up performance a lot ... then you have to explain to developers that even if they think they are writing with "use strict" they are not since after minification that directive will be most likely gone so they have zero gain except while writing/testing non production code before minification (here those tools you mentioned can be useful for strict behaviors, not after on real world, IMHO)
> 
> br
> 
> 
> On Thu, Nov 15, 2012 at 12:38 PM, Oliver Hunt <oliver at apple.com> wrote:
> 
> On Nov 15, 2012, at 12:33 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
> 
>> also, take a break if you have time and enjoy this talk: http://www.youtube.com/watch?v=MFtijdklZDo
>> 
>> 
>> On Thu, Nov 15, 2012 at 12:32 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
>> funny, 'cause at least one use case I have implemented, is about improving performances at least 2X for 99% of OOP frameworks out there ... I guess you like function wrappers then to simulate caller when needed, right?
>> 
>> Anyway, thanks ... I'd like to hear the same from some TC39 guy if you don't mind and you are not already otherwise I'll stop here.
> 
> You mean a TC39 member like me?
> 
> If you have specific examples, you can file bugs on the various engines where the performance hit is excessive (2x obviously being excessive).
> 
> --Oliver
> 
> 
>> 
>> br
>> 
>> 
>> On Thu, Nov 15, 2012 at 12:29 PM, Oliver Hunt <oliver at apple.com> wrote:
>> 
>> On Nov 15, 2012, at 12:17 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
>> 
>>> the debugger you mention is most likely using the with statement ... 
>> 
>> No, the debugger is part of the virtual machine.  I'm aware that the WebKit inspector currently has a rather annoying bug wrt executing code in strict mode, but that's a _bug_.
>> 
>>> 
>>> Can we just stick with the answer if it is planned or not? I don't want to convince you that there are cases where non strict features are needed ... it is just like that and many times already discussed.
>> 
>> Not planned.
>> 
>>> Again, is there any real reason to not consider a "no strict" directive? The whole web is running no strict thanks to minifiers so I really would like to listen to real reasons over already discussed academic debates.
>> 
>> Because it would complicate the language, the implementation, and have negative performance consequences.
>> 
>> --Oliver
>> 
>>> 
>>> 
>>> 
>>> On Thu, Nov 15, 2012 at 12:10 PM, Oliver Hunt <oliver at apple.com> wrote:
>>> 
>>> On Nov 15, 2012, at 11:58 AM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
>>> 
>>>> my typo ... I am NOT talking about callee, I am talking about caller which is NOT a misfeature specially when it comes to debug and stack trace.
>>> 
>>> The solution to debugging is to use a debugger, not to try and debug from within the language.
>>> 
>>> All modern JS engines provide a) a debugger and b) stack traces on exceptions.
>>> 
>>> Even if they weren't .caller is insufficient: it can't walk over strict, native, or global code that exists in the call stack, so at best you only get a crappy result.
>>> 
>>> Like I said in my prior email: If you're willing to toss out the improvements of strict mode just to get arguments.caller, you may as well stop using it in the first place.
>>> 
>>> --Oliver
>>> 
>>>> 
>>>> 
>>>> On Thu, Nov 15, 2012 at 11:55 AM, Oliver Hunt <oliver at apple.com> wrote:
>>>> 
>>>> On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
>>>> 
>>>> > I wonder if there is any plan to allow a chunk of code to disable for its own closure purpose a previously called "use strict"; directive.
>>>> >
>>>> > This is about the ability to use, when not possible otherwise, some good old feature such caller which is impossible to replicate when use strict is in place.
>>>> >
>>>> > I am talking about arguments.callee, I am talking about caller.
>>>> 
>>>> arguments.callee and .caller are not good features.
>>>> 
>>>> Being able to access your caller is a misfeature.
>>>> 
>>>> arguments.callee is simply unnecessary.
>>>> 
>>>> Also having the ability to lose strict semantics at arbitrary locations in the middle of other strict modes makes things even slower, and adds all sorts of weird semantic behaviours (eg. what would eval('"no strict"; var x;') do? -- this is hypothetical, just given as a trivial example of where things go weird)
>>>> 
>>>> --Oliver
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121115/dd7f7df5/attachment.html>


More information about the es-discuss mailing list