Jasvir Nagra
On Thu, Nov 15, 2012 at 1:43 PM, Andrea Giammarchi < [email protected]> 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 <[email protected]> wrote: > >> On Nov 15, 2012, at 1:15 PM, David Herman <[email protected]> wrote: >> >> > On Nov 15, 2012, at 1:04 PM, Allen Wirfs-Brock <[email protected]> >> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
