sure, but I believe Mark did before me and SES fixed this issue indeed. I
understand it's different behind the scene, I don't understand why "use
strict" , which aim is to make code more secure, better, faster, can be
easily deactivated like that. I am talking about 3rd parts libraries that
could decide to run **non strict** inside whatever "use strict" environment
due that Function/(1,eval) door.
If this is not risky then I am missing what is this "use strict" about
since there were already linters to tell us what's good and what's not on
code level, I am sorry if I don't understand.
br
On Fri, Nov 16, 2012 at 3:52 PM, Oliver Hunt <oli...@apple.com> wrote:
>
> On Nov 16, 2012, at 3:38 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> you hear Mark? drop that SES solution. Is good to evaluate in the same
> scope and context with a directive disabled inline and please read specs! (
> sorry I could not resist but Oliver you are fun, I am going to read specs
> now :-) )
>
>
> I'm not sure where you got that from, if you felt I was being offensive I
> apologise, but I'm serious, you need to read the spec; There are very
> real, and very important semantic differences between using eval as an
> operator, and calling any other function. Likewise there are very
> important behavioural differences between accessing the arguments value
> inside a function body, and accessing the caller property of a function
> object. There are major semantic differences between the concepts of a
> function object, a function's environment record, and the function code
> itself. To meaningfully discuss the behaviour and semantics of these
> things (and their interactions with strict mode) you need to understand all
> of these concepts and how they relate.
>
> --Oliver
>
>
>
> On Fri, Nov 16, 2012 at 3:32 PM, Oliver Hunt <oli...@apple.com> wrote:
>
>> I don't think you understand the semantics here -- the Function
>> constructor is defined as taking a string (ignoring the parameters for now)
>> and returning a function as though the function was defined in the global
>> scope. No functions change behaviour based on the strictness of their
>> caller. The only way to make a string execute as javascript inside the
>> scope of another function is to use the eval _operator_. These are
>> fundamentally different concepts.
>>
>> To put it another way, if the Function constructors behaviour was
>> dependent on the strictness of its caller, i would expect:
>> document.write("<script>/*code here*/</"+"script>");
>>
>> to produce an script element that was already in strict mode.
>>
>> You really need to read the spec, as you seem to be misunderstanding some
>> very fundamental concepts.
>>
>> --Oliver
>>
>> On Nov 16, 2012, at 3:19 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>> back in the topic ... about evaluation: Function('return this')();
>> returns the global object with or without use strict around. This is
>> actually nice, since this one was a security problem introduced when
>> somebody decided that `this` without an explicit context should have been
>> undefined. Now it is possible to retrieve the global object as long as
>> Function is the original constructor.
>> Said that, I believe this is a bug in every browser. (Webkit, FF, Chrome
>> suffering)
>>
>> Please do not fix, thanks :-)
>>
>>
>> On Fri, Nov 16, 2012 at 2:50 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> love this answer, thanks!
>>>
>>>
>>> On Fri, Nov 16, 2012 at 2:47 PM, Jeff Walden <jwalden...@mit.edu> wrote:
>>>
>>>> On 11/16/2012 02:37 PM, Andrea Giammarchi wrote:
>>>> > what I am saying: arguments won't disappear in 5+ years, neither will
>>>> caller ... is my crystal ball correct?
>>>>
>>>> It's not necessary for these things to disappear completely for us to
>>>> derive value from these decisions. It's only necessary for good code, that
>>>> wants to be performant, to not use them.
>>>>
>>>> Jeff
>>>>
>>>
>>>
>> _______________________________________________
>> 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
