a future caller alternative ?

Kevin Gadd kevin.gadd at gmail.com
Fri Mar 8 13:25:58 PST 2013

The way caller is a single attribute of the function object arguably makes it useless for authoring reusable code: it breaks in the presence of reentrance, and requires you to keep an accessible reference to every function that might want to know its caller, exposing you to leaks and making closures harder to use in such scenarios.

The problems it's intended to solve are important, but it's a really poor solution to them. I'd love to see caller dead for good and a well engineered solution take its place.
-kg (mobile)

Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

>I wonder if there's any discussion about it for ES.next
>while callee has always been kinda pointless in my opinion, caller
>is not replaceable at all.
>Internally, for scope lookup reasons, the caller is always passed
>except, I guess, where there's no caller access and the function is
>optimized thanks to absent outer scope look up.
>Why caller? Because there's no other way to understand which method
>a getter, as the very most basic example.
>var obj = Object.defineProperty({}, "caller", {get: function get(){
>  return get.caller;
>obj.method = function method() {
>  alert(this.caller === method);
>This opens doors to debuggers (introspection) and APIs magic quite a
>2 extra points:
>1) I have not even mentioned arguments, which is not mandatory for
>  2) I haven't used callee and I don't care about callee
>Last, but not least, the more I think about the inability to switch
>mode" in the wild the more patterns from ES3 injected into ES.next come
>in my mind.
>Thanks for any sort of response
>es-discuss mailing list
>es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130308/c53a4952/attachment.html>

More information about the es-discuss mailing list