"no strict"; directive

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu Nov 15 13:43:07 PST 2012

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:

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:

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.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121115/c936d05b/attachment.html>

More information about the es-discuss mailing list