On Fri, Mar 8, 2013 at 1:32 PM, Andrea Giammarchi < [email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
