"no strict"; directive

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Nov 16 13:42:03 PST 2012

@Oliver, if you need to retrieve the caller in order to know if it's strict
or not, then everything I've read in this thread becomes kinda pointless :-(

It looks like there's no gain at all using strict and the goal here is
"simply" to get rid of these calls exec->interpreter
()->retrieve*something*FromVMCode(exec, thisObj);

am I wrong? Can I ask when and if it's planned to get rid of this
isStrictMode() method? This, as info, would be definitively valuable ( FF
and Chrome guys welcome to answer to this as well, thanks )

On Fri, Nov 16, 2012 at 1:01 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> P.S. Alex, just to be as clear as possible, one answer I did not like that
> much was that eval('"no strict"') nonsense ... that was not an answer
> 'cause problems are the same with eval('"use strict"') and we, JS
> developers, are not always noobs or dumb.
> It happens, from time to time, that we know what we are talking about and
> why we need this or that thing.
> It's nice when here we keep it easy and quite ... it's also rare, imho.
> On Fri, Nov 16, 2012 at 12:57 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>> neither does `with` so the day use strict will be the default 90% of
>> tests frameworks will nicely break as well.
>> There are tons of libraries still based on ES3 and those "evil" things.
>> I am the first one to use always latest, and use strict too, but there
>> are cases where those "evil" things cannot be replaced and maybe are useful
>> and for good.
>> As long as there is a "no strict" behavior supported by engines I am good
>> in any case but it's a pity we cannot have that solution today .. is the
>> only one that makes sense out there, the only that does not suffer all
>> other problems plus does not impact performance of each methods when super
>> call is something actually not that common or not always needed when
>> inheritance is in place.
>> I've solved this a while ago with a better approach, even better than the
>> currently de-sugared TypeScript, but developers are lazy and this new
>> solution would have made them happy in their laziness.
>> Thank everyone in any case for all inputs and thoughts and facts, I guess
>> I am done here.
>> br
>> On Fri, Nov 16, 2012 at 12:38 PM, Alex Russell <alex at dojotoolkit.org>wrote:
>>> I'm a huge fan of that too -- you know I don't like compilers as the
>>> answer -- but that approach always comes with limits; and that's OK. What
>>> we add to the spec lives forever; not just through the transition. We owe
>>> it to ourselves and our users to introduce the least crazy we can while
>>> still solving the most pressing problems; and to do it with an eye toward
>>> living in the future were specing. Caller doesn't pass this smell test.
>>>  On Nov 16, 2012 4:55 PM, "Andrea Giammarchi" <
>>> andrea.giammarchi at gmail.com> wrote:
>>>> I am still a big fun of what made JS easy to use, develop, learn since
>>>> born ... the ability to include a script in a HTML page and run it without
>>>> being forced of using different tools in the middle before results or even
>>>> requiring a web server at all.
>>>> I remember once I've read that scripting was cool 'cause no time wasted
>>>> compiling ... those days are gone in modern JS development.
>>>> br
>>>> On Fri, Nov 16, 2012 at 6:01 AM, Alex Russell <alex at dojotoolkit.org>wrote:
>>>>> On Nov 16, 2012, at 1:02 AM, Andrea Giammarchi <
>>>>> andrea.giammarchi at gmail.com> wrote:
>>>>> > "use strict" is removed from code by default ... this is where it
>>>>> goes once
>>>>> > minified: nowhere.
>>>>> >
>>>>> > I would rather force a minifier explicitly to remove it rather than
>>>>> force
>>>>> > it to keep it for ES5 ... also ES5 is not use strict so I don't get
>>>>> this
>>>>> > Closure Compiler choice.
>>>>> >
>>>>> > I don't see minified code with "use strict" that often
>>>>> All this suggests is that we need to improve the state of play in
>>>>> tools. Sounds doable.
>>>>> That said, you've gotten good answers that you don't like. It happens,
>>>>> and it's better than not getting an answer or getting a bad one.
>>>>> The polyfill you're working on can be accomplished other ways (
>>>>> http://code.google.com/p/traceur-compiler/). There's always a tax for
>>>>> emulating the new thing with the old, and this case that's caller. More to
>>>>> the point, it's a polyfill; once ES6 lands in engines, class syntax will
>>>>> give you super() for free, complete with whatever optimizations make sense.
>>>>> If you have performance issues, I recommend what everyone else here
>>>>> has: write benchmarks and file bugs. Beyond that, I think this horse is
>>>>> both dead and beaten.
>>>>> > On Thu, Nov 15, 2012 at 4:40 PM, Brendan Eich <brendan at mozilla.com>
>>>>> wrote:
>>>>> >
>>>>> >> Andrea Giammarchi wrote:
>>>>> >>
>>>>> >>> Said that, I would rather force removal of "use strict" 'cause if
>>>>> there
>>>>> >>> is explicit desire from the developer. Isn't it?
>>>>> >>>
>>>>> >>
>>>>> >> What do you mean? "use strict" is not going away. It is used by some
>>>>> >> developers. I had a show of hands at JSConf.au, definitely a
>>>>> minority but
>>>>> >> significant.
>>>>> >>
>>>>> >> You are barking up the wrong tree. And Angus's abuses of 'with' are
>>>>> >> unjustified. Yes, "be water". Yes, masters may break rules students
>>>>> must
>>>>> >> follow. None of that philosophizing justifies 'with' abusage or
>>>>> >> repealing/undoing "use strict".
>>>>> >>
>>>>> >> /be
>>>>> >>
>>>>> > _______________________________________________
>>>>> > es-discuss mailing list
>>>>> > es-discuss at mozilla.org
>>>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>>> --
>>>>> Alex Russell
>>>>> slightlyoff at google.com
>>>>> slightlyoff at chromium.org
>>>>> alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121116/907a7b2d/attachment-0001.html>

More information about the es-discuss mailing list