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. br On Thu, Nov 15, 2012 at 1:16 PM, David Herman <dher...@mozilla.com> wrote: > On Nov 15, 2012, at 1:15 PM, David Herman <dher...@mozilla.com> wrote: > > > On Nov 15, 2012, at 1:04 PM, Allen Wirfs-Brock <al...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
