The Error.stack strawman is a great start at making Error.stack's contents machine-readable, but doesn't remotely approach being a solution for use cases previously addressed by Function.caller.
I don't really understand the security argument in this case. Being able to identify the particular function at offset N in the stack shouldn't expose any privileged information, unless you're somehow assuming that this would expose locals or closed-over values... it's not my understanding that this was the case originally with caller and I don't know off hand of any use cases that would address other than debugger use cases (Which, as you mention, are best addressed by a debugging API). If anything, being able to cheaply and reliably walk the stack to - for example - identify your caller would allow you to implement some interesting security patterns in your own code, if for some reason you were trying to do sandboxing and code access security in pure JS. If specified correctly you could make it possible to walk the stack and ensure that the information you're getting isn't being spoofed, which would allow you to reliably limit callers of a given 'protected' function to a fixed whitelist of trusted functions, something you can't do by parsing a dead stack trace. Error.stack is also a terrible choice for any scenario where you want adequate performance. I don't expect stackwalking to ever be *fast*, but there's a huge difference between 'give me the identity of my caller' and 'turn the entire call stack into a string, and also, construct an exception instance since that's how I'm getting the stack'. I agree with Andrea that the loss of caller in strict mode was painful and it would be troublesome if that feature set is gone forever. It's one of the reasons I periodically consider ceasing to generate strict-mode code in my compiler. A key point I want to make here: Debugging is not the only reason people will want to walk the stack. It is possibly the best and most common reason, but in the wild I regularly encounter applications that use limited forms of stack-walking for other purposes: Code access security, metaprogramming, logging, etc. These are all reasonable use cases, and in particular I think code access security and detailed logging are both use cases that one could argue should deliver reasonable performance as well, unless your goal is to instead handle those use cases entirely with special features baked into the language or libraries. Apologies if I've missed some huge design philosophy underpinning the design of ES6/ES7 re: security/sandboxing; I also don't really know/understand how Caja fits into the picture. -kg On Fri, Mar 8, 2013 at 1:49 PM, Mark S. Miller <erig...@google.com> wrote: > On Fri, Mar 8, 2013 at 1:32 PM, Andrea Giammarchi > <andrea.giammar...@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.g...@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.giammar...@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@mozilla.org >>>> >>>> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> _______________________________________________ >> >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > -- > Cheers, > --MarkM -- -kg _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
