"no strict"; directive

Oliver Hunt oliver at apple.com
Thu Nov 15 12:38:55 PST 2012


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/e3e7634c/attachment.html>


More information about the es-discuss mailing list