User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a) Gecko/20040519 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a) Gecko/20040519 caller was finally returned to Function object which makes complex app easier to debug after deployment. Still we have problems to determine cause of problem from stacktrace with function names only. Attached patch adds callerln property to Function which reflects line in caller we was called from. I'm not sure if the name is ok (callerline may be better) but I feel that it might be useful function. As it is extension, one should always check its presence like: s += f.caller.name+(f.callerln?":"+f.callerln:""); Reproducible: Always Steps to Reproduce: 1. 2. 3.
14 years ago
I think we don't want more non-standard properties in function objects. ECMA allows such extensions, but they risk colliding with "static properties" of functions used as class constructors. If the name is ugly enough, the risk can be considered ~0. But there's the code overhead too. Function.prototype.caller does not link to activations, rather to functions, so recursive cycles are not backtraceable with it. Still, it's useful to folks such as the TIBET guys (cc'ing them). Would a callerLine or __callerLine__ be useful enought o warrant the small code space increase, assuming we can finesse the name collision risk? /be
Brendan - Thanks for keeping us in the loop. Right now, this would be a 'nice to have' for us, as we're intently looking at integrating the JS debugger hooks that you guys did into the next (GUI) version of our IDE for our debugging purposes. '__noSuchMethod__' was a much 'bigger win' hook for us. Of course, I'll never turn down new features, if you want to add them :-). I'll note, for completeness, that the JScript engine kept the 'arguments.caller' hook in all the way through JScript 5.6 (the version that comes with IE6) and we do use it for stack backtracing, etc. when the property is present. Its nice to be able to 'log' the arguments that were passed to a particular method up the stack, etc. Thanks! - Bill (the guy who will probably be forever remembered as 'the big whiner when arguments.caller was removed from Spidermonkey' :-))
I agree and feel too that removal of arguments.caller is a bit unfortunate from app developer's view. We was forced to convert recursive calls to stacked ones to be able to see complete backtraces in Mozilla. I read somewhere that there was not only security but also performance reasons - I don't understand the latter. Also when disalowing arguments.caller where caller's activation record has function object with foreign source (different domain) then I don't get what security problem was there... Still I hope for __callerLine__-like functionality - to be able to differentiate two calls in the same body al least by line (when I can't do it by arguments).
Comment on attachment 148835 [details] [diff] [review] Adds callerln to Function Let's not hack more non-standard properties here. Someone motivated should instead write a patch to implement http://wiki.ecmascript.org/doku.php?id=proposals:stack_inspection /be
Closing as WONTFIX per comment 5. (In reply to comment #5) > Let's not hack more non-standard properties here. Someone motivated should > instead write a patch to implement > > http://wiki.ecmascript.org/doku.php?id=proposals:stack_inspection > > /be