"no strict"; directive

๏̯͡๏ Jasvir Nagra jas at nagras.com
Thu Nov 15 14:58:06 PST 2012


Jasvir Nagra



On Thu, Nov 15, 2012 at 1:43 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> have to dig about the Engines problems, I assumed it was a matter of "hey,
> I am your parent caller" pointer and nothing else.
>
> Said that, you want a use case, here:
> https://github.com/WebReflection/poo/blob/master/src/superable.js
>
> This let you make any object superable so that you can access this.super()
> as it is specified in ES6 (without this. but that's not convenient to
> pollute the global scope with a "super" getter and without a context)
> without impacting performance at all unless the method is accessing that
> super. In latter case yes, you have a performance impact and it's going to
> be probably slower than other solutions but it's about having everything
> else at the same speed except when you do need super access and not every
> time you call a method.
>
> More over, you don't need a central uniq entry point to share superable so
> that different libraries could extend each other without problems.
>
> This is not possible if the code is under use strict directive, this is
> why I had to update also require_client to force all code to be evaluated
> without that directive once minified:
> https://github.com/WebReflection/require_client
>
> About minifiers, Google Closure compiler and YUI are only two examples ...
> do you know anyone better than these two that by default does not change
> the "use strict" behavior? That would be nice to know, thanks.
>

I am not sure why "by default" matters.  Closure compiler takes a flag
--language_in=ECMASCRIPT5_STRICT and preserves strictness.

br
>
>
> On Thu, Nov 15, 2012 at 1:16 PM, David Herman <dherman at mozilla.com> wrote:
>
>> On Nov 15, 2012, at 1:15 PM, David Herman <dherman at mozilla.com> wrote:
>>
>> > On Nov 15, 2012, at 1:04 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
>> wrote:
>> >
>> >> On Nov 15, 2012, at 12:37 PM, Andrea Giammarchi wrote:
>> >>
>> >>> I believe with is much more problematic than caller for all Engines
>> out there. A reference to "who is invoking" cannot be that bad ... is it?
>> >>
>> >> Yes it is!  It is a capability leak.  It give a callee access to
>> functions that would otherwise be inaccessible to the callee.  Who knows
>> what mischief can be accomplished by calling such functions.
>> >
>> > What's more, it's totally inadequate as a stack walking tool. If any
>> function appears twice in a call stack (most commonly in the presence of
>> recursion), you can't walk the whole stack. You either have to detect the
>> repeat and give up, or loop infinitely. So in addition to being a security,
>> performance, and engineering nightmare, arguments.caller is pretty much
>> useless.
>>
>> And to be clear, it *is* a problem for engines: it prevents proper tail
>> calls (or even tail call optimization).
>>
>> Dave
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> 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/20121115/08eb380d/attachment.html>


More information about the es-discuss mailing list