Adding callerln to Function object

RESOLVED WONTFIX

Status

()

Core
JavaScript Engine
--
enhancement
RESOLVED WONTFIX
14 years ago
7 years ago

People

(Reporter: Martin Devera, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

14 years ago
Created attachment 148835 [details] [diff] [review]
Adds callerln to Function
Attachment #148835 - Flags: superreview?(brendan)
Attachment #148835 - Flags: review?(brendan)
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
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

14 years ago
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' :-))
(Reporter)

Comment 4

14 years ago
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).

Updated

13 years ago
QA Contact: pschwartau → general
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
Attachment #148835 - Flags: superreview?(brendan)
Attachment #148835 - Flags: review?(brendan)
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
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.