a future caller alternative ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Mar 8 13:59:04 PST 2013

Thanks Mark,
    my point is that "use strict" deprecated things without providing

monocle mustache instead of with is nice to have (unfortunately it breaks

..args instead of arguments is cool too

callee ain't needed since named function expression exists

caller ? As I've said the introspection is just one cool aspect of caller,
new APIs compatible with "use strict" could be something awesome for
developers too.

Thanks to its dynamic nature, is quite easy to wrap all global functions
and all objects functions with wrappers that store the latest invoked
callback somewhere for a global caller but this is a monster against quite
elegant solution caller has been for long time (and I've never had those
problems, I've always addressed caller once, when needed, at the top of the
function and never accessed again so never a problem, IMO)

If this decision could be made with tc39 that's already something ... is
the silence I hear around caller that worries me :-)

On Fri, Mar 8, 2013 at 1:49 PM, Mark S. Miller <erights at google.com> wrote:

> 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 <
> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js
> >.
>> 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
> --
>     Cheers,
>     --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130308/c1303a59/attachment.html>

More information about the es-discuss mailing list