[rnd me]

ecma6 bans the arguments.caller in strict, ecma5 left it alone.
arguments.caller was never defined, and don't recommend anyone use it.
It's arguments.callee.caller that works in all browsers i tested (unless you disable it with strict).

One thing that i think is funny is that you can do this:

alert(Function('a',' "use strict"; return a*a;')(123))

Thanks for looking into a work around. Looks like we're stuck with dynamic code generation if we want raw power and less typing.


Sadly, Function is not avail under strict either, but <scirpt src=dataURLs> is, so we just have to rewrite all the function-type globals we find with the new code, encode that as a dataURL, inject the script, and resume on onload, ready, or wherever else it was waiting on us.

That will let me not only fix arguments, it can add in a lot of missing features and fix common shortcomings and errors.

basically, it's a play off of coffeescript, except that it uses valid JS syntax instead of something that must be delivered as a string. to scan the globals, i use something like this:

Object.keys(window).filter(function(a){
   if(window[a] && window[a].call && !String(window[a]).match(/\[native code\]/) && String(window[a]).match(/\bfor/)  ){ 
     return true;
    }
})

I see this as THE solution to a lot of things going forward.

which gives me a list of all global user-land functions. I then grab those functions, make string replacements, and putting them in an output array. Ex: rewriting "ARGS" to "[].slice.call(arguments)". The output array is then joined, turning the functions into code, and that code is injected into the page using a dataURL-based script to avoid a direct call to eval.
there would be no chance of "use strict" making it into the "file", so it should work work regardless of other code.


The code in the OP was more of a discovery than an invention; i couldn't belive it would work without eval, and left me wondering how come i didn't see such delightful magic earlier: it's worked for a long time now...


one last hurrah (sorry can't resist: you started it...)
the opening intro of the MDN article call strict mode a subset (though not JUST one) and says it's an opt-in variant, not the future path forward:

ECMAScript 5's strict mode is a way to opt in to a restricted variant of JavaScript. Strict mode isn't just a subset: it intentionally has different semantics from normal code.