@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 :-(
https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/JSFunction.cpp#L184
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.giammar...@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.giammar...@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 <a...@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.giammar...@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 <a...@dojotoolkit.org>wrote:
>>>>
>>>>> On Nov 16, 2012, at 1:02 AM, Andrea Giammarchi <
>>>>> andrea.giammar...@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 <bren...@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@mozilla.org
>>>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>> --
>>>>> Alex Russell
>>>>> slightly...@google.com
>>>>> slightly...@chromium.org
>>>>> a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
