By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,700 Members | 1,663 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,700 IT Pros & Developers. It's quick & easy.

How to get the object method name?

P: n/a
It's not difficult getting the function name of the caller but if the
caller is an object's method, how do you get the method name?

<html>

<head>
<script type="text/javascript">
function displayCallStack(func){

var caller = func.caller;
if(caller == null) return;

console.log(caller);
displayCallStack(caller);
}

function objectA(){
}

objectA.prototype.method1 = function(){

test();
}

var obj = new objectA();
function test(){
test1();
}

function test1(){
displayCallStack(displayCallStack);
}
</script>

<body onload="obj.method1()">

</body>

</html>

Here is the result:
test1()
test()
function()
onload(event)

Ideally, I like the output to be
test1()
test()
obj.method1()
onload()

Your help is highly appreciated!

Nov 12 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a

ja********@gmail.com wrote:
It's not difficult getting the function name of the caller but if the
caller is an object's method, how do you get the method name?

<html>

<head>
<script type="text/javascript">
function displayCallStack(func){

var caller = func.caller;
if(caller == null) return;

console.log(caller);
displayCallStack(caller);
}

function objectA(){
}

objectA.prototype.method1 = function(){

test();
}

var obj = new objectA();
function test(){
test1();
}

function test1(){
displayCallStack(displayCallStack);
}
</script>

<body onload="obj.method1()">

</body>

</html>

Here is the result:
test1()
test()
function()
onload(event)

Ideally, I like the output to be
test1()
test()
obj.method1()
onload()

Your help is highly appreciated!
Well, I'm not sure you can do that. The function you're trying to get
name of, actually hasn't got any
name - it's an anonymous function, a reference to which is stored in a
variable. Using that variable, you call the anonymous function. It is
the same as the following:

var a, b;
a = b = function()
{
// ... now you try to get which variable was used to call the
function
}

a();
b();

I think Javascript hasn't implemented such mechanisms, at least I
don't know of any.

Regards

Nov 12 '07 #2

P: n/a
ja********@gmail.com wrote:
It's not difficult getting the function name of the caller
Depends. The property you are using is not part of any standard and so
is not supported in all implementations, e.g. not in Opera 9.2.[34].
but if the caller is an object's method, how do you get the method name?
The only possibility that comes to my mind is to iterate through the
enumerable properties of the object and to compare the property access
with the caller reference. The only problem then is to know the object.
[...]
function displayCallStack(func){

var caller = func.caller;
if(caller == null) return;

console.log(caller);
displayCallStack(caller);
In JavaScript there is the `stack' property for Error objects. You can
throw an exception and then evaluate the property value.

function a()
{
try {
throw new Error();
}
catch (e)
{
window.alert(e.stack);
}
}

function b()
{
a();
}

b();

I don't know about JScript and other implementations, though.

That said, other than for educational purposes, there is no good reason why
one would need to get the stack trace in the script that is debugged. From
the console.log() call I assume you use or at least support Firebug, which
provides the stack trace along with the error message. Just click the "+"
icon next to the error message.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Nov 15 '07 #3

P: n/a
Thomas 'PointedEars' Lahn a écrit :
That said, other than for educational purposes, there is no good reason why
one would need to get the stack trace in the script that is debugged. From
the console.log() call I assume you use or at least support Firebug, which
provides the stack trace along with the error message. Just click the "+"
icon next to the error message.
There is plenty of good reasons to do it. For example, dont confuse your
non technical users with something they can't understand like firebug
and still get realistics error messages with call stack instead of the
usual "It is not working on my computer".

--
laurent
Nov 15 '07 #4

P: n/a
Laurent vilday wrote:
Thomas 'PointedEars' Lahn a écrit :
>That said, other than for educational purposes, there is no good reason why
one would need to get the stack trace in the script that is debugged. From
the console.log() call I assume you use or at least support Firebug, which
provides the stack trace along with the error message. Just click the "+"
icon next to the error message.

There is plenty of good reasons to do it. For example, dont confuse your
non technical users with something they can't understand like firebug
and still get realistics error messages with call stack instead of the
usual "It is not working on my computer".
If users are bothered with code that actually *breaks* at all then it is the
developer's fault for not taking the possibility of failure of a line when
exposed to that execution environment into account. It is irresponsible,
inept and ultimately incompetent behavior to let users be beta-testers,
unless they want to. And in the latter case they will understand how to use
Firebug, or the built-in error console of the HTML user agent, for that matter.
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Nov 15 '07 #5

P: n/a
Thomas 'PointedEars' Lahn a écrit :
Laurent vilday wrote:
>Thomas 'PointedEars' Lahn a écrit :
>>That said, other than for educational purposes, there is no good reason why
one would need to get the stack trace in the script that is debugged.
There is plenty of good reasons to do it. For example, dont confuse your
non technical users with something they can't understand like firebug
and still get realistics error messages with call stack instead of the
usual "It is not working on my computer".

If users are bothered with code that actually *breaks* at all then it is the
developer's fault for not taking the possibility of failure of a line when
exposed to that execution environment into account.
Will you ever open your mind and your eyes to the real world ?

Everything is breaking in one or another way. In real world, clients are
paying for a product (a website, an intranet, anything web related) and
all the time is not used to add new shinny features to the product. Most
of the time is used to work around bugs to finally get a consistent
behavior in the most used browsers. Not talking about accessibility
nightmare.

Well, it's not totally true, few people like me, and probably you I
assume, have plenty of time to learn and play with the languages they
want and create the tools the way they want. But at work, most of my
colleague dont have this luxury. They have dead lines, they have
schedules. They can't afford to test everything in every situations.

So yes, time to time it happens to break. No big deal, the developer
will fix it.
It is irresponsible,
inept and ultimately incompetent behavior to let users be beta-testers,
unless they want to.
So, basically, users with zero technical knowledges can bring nothing to
developers ? Please, open your mind.
And in the latter case they will understand how to use
Firebug, or the built-in error console of the HTML user agent, for that matter.
You don't have much imagination, don't you ?

Perhaps it is someone surveying the work of someone else in a real
situation to, for instance, find a problem. There is plenty of good
reasons, even in debugged scripts. Perhaps not everytime at every moment
and every seconds, but in real world any situation can happen. Just need
an open mind.

I am beginning to wonder, are you just a troll ?

--
laurent
Nov 15 '07 #6

P: n/a
Laurent vilday said the following on 11/14/2007 8:59 PM:
Thomas 'PointedEars' Lahn a écrit :
>Laurent vilday wrote:
>>Thomas 'PointedEars' Lahn a écrit :
That said, other than for educational purposes, there is no good
reason why
one would need to get the stack trace in the script that is debugged.
There is plenty of good reasons to do it. For example, dont confuse
your non technical users with something they can't understand like
firebug and still get realistics error messages with call stack
instead of the usual "It is not working on my computer".

If users are bothered with code that actually *breaks* at all then it
is the
developer's fault for not taking the possibility of failure of a line
when
exposed to that execution environment into account.

Will you ever open your mind and your eyes to the real world ?
If the past 2-3 years are any indication, no.

<snipped explanation of reality>
So yes, time to time it happens to break. No big deal, the developer
will fix it.
Don't try to explain Reality to Thomas, he doesn't comprehend it. It
doesn't fit into his "Perfect Theoretical World".
>It is irresponsible,
inept and ultimately incompetent behavior to let users be beta-testers,
unless they want to.

So, basically, users with zero technical knowledges can bring nothing to
developers ? Please, open your mind.
You sure have lofty goals :)

<snip>
I am beginning to wonder, are you just a troll ?
Laurent, meet Thomas. You have him figured out now :)

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 15 '07 #7

P: n/a
Laurent vilday wrote:
Thomas 'PointedEars' Lahn a écrit :
>Laurent vilday wrote:
>>Thomas 'PointedEars' Lahn a écrit :
That said, other than for educational purposes, there is no good
reason why one would need to get the stack trace in the script that
is debugged.
There is plenty of good reasons to do it. For example, dont confuse
your non technical users with something they can't understand like
firebug and still get realistics error messages with call stack
instead of the usual "It is not working on my computer".
If users are bothered with code that actually *breaks* at all then it
is the developer's fault for not taking the possibility of failure of a
line when exposed to that execution environment into account.

Will you ever open your mind and your eyes to the real world ?
I live in the real world. I just don't want to live in the kind of "real
world" you want to live in where you don't take responsibility for your actions.
Everything is breaking in one or another way.
Not if properly tested. A feature may not work in all environments but that
is far from *breaking*.
In real world, clients are paying for a product (a website, an intranet,
anything web related) and all the time is not used to add new shinny
features to the product. Most of the time is used to work around bugs to
finally get a consistent behavior in the most used browsers.
Proper testing is what should take place *before* shipping any product.
Not talking about accessibility nightmare.
Red herring. The so-called "accessibility nightmare" is not subject to
script errors.

And again, there is no "accessibility nightmare" if there are competent
developers. Especially not with ECMAScript implementations in a Web
context where there are plenty *built-in* possibilities for graceful
degradation.
I am beginning to wonder, are you just a troll ?
I am beginning to wonder, are you just a script-kiddie?
Score adjusted

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>
Nov 15 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.