a future caller alternative ?

Mark S. Miller erights at google.com
Fri Mar 8 13:49:21 PST 2013

On Fri, Mar 8, 2013 at 1:32 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> I'd love to see caller dead **only** after a well engineered solution take
> its place and is widely adopted, which is the reason I've asked about this
> future solution I've never seen discussed here.
> So, the question is: is there any plan to discuss, to put in agenda, to
> bring, a "caller" alternative to ES.next ?

There are several JSON RPC debugging APIs for remote debugging of JS
processes. There is even some convergence among them. I have not followed
these developments for a good long while, but when I did it seemed ripe
for codification into a standard. I think this would be a wonderful thing
to see, and could lead to platform independent portable debuggers for JS,
much as Java Platform Debugger Architecture (JPDA) has done for Java. I do
*not* think this should be part of ES.next in the sense of being
incorporated into a future version of Ecma 262. Rather, I think it should
be on a separate tc39 track, in the same sense that the i18n effort is.

Outside of a debugging API, access to the live stack is a security hole,
much as is access to the state encapsulated in a closure. As for access to
data representing a dead snapshot of a stack, there's <
http://wiki.ecmascript.org/doku.php?id=strawman:error_stack>, which is a
good start. As that page notes, we should still be concerned about the
information leak, but we can handle that well by hiding the access in a
WeakMap. See the API at <

> Thanks
> On Fri, Mar 8, 2013 at 1:25 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:
>> 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
>>> property is not replaceable at all.
>>> Internally, for scope lookup reasons, the caller is always passed
>>> somehow, 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
>>> invoked 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 lot.
>>> 2 extra points:
>>>   1) I have not even mentioned arguments, which is not mandatory for
>>> caller
>>>   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
>>> "strict mode" in the wild the more patterns from ES3 injected into ES.next
>>> come up in my mind.
>>> Thanks for any sort of response
>>> ------------------------------
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> 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/20130308/b24a653a/attachment-0001.html>

More information about the es-discuss mailing list