How to get the object method name?

J

jackchang1

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!
 
D

Darko

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
 
T

Thomas 'PointedEars' Lahn

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
 
L

Laurent vilday

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".
 
T

Thomas 'PointedEars' Lahn

Laurent said:
Thomas 'PointedEars' Lahn a écrit :

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
 
L

Laurent vilday

Thomas 'PointedEars' Lahn a écrit :
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 ?
 
T

Thomas 'PointedEars' Lahn

Laurent said:
Thomas 'PointedEars' Lahn a écrit :

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,780
Messages
2,569,611
Members
45,280
Latest member
BGBBrock56

Latest Threads

Top