arguments.callee.name vs. functionName.name?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

-Lost - 27 Jan 2007 19:04 GMT

What in the world is functionName.name good for? That is:

function functionName() { return functionName.name; }

I mean, I already had to write out the function's name so it seems that it is not very
useful or efficient.

To me, this.name seems most appropriate, but of course that does not work within the
context of a function unless defined as a class, which of course then the name property
does not apply to the calling function.

Of course, you could always assign it yourself like:

function functionName() { this.name = arguments.callee.name; }

But anyway... my original question, what is the purpose of using functionName.name as
opposed to arguments.callee.name? (The second being useful, efficient and dynamic.)

Thanks.

-Lost

Reply to this Message

VK - 27 Jan 2007 21:32 GMT

> What in the world is functionName.name good for?

Given that it is not supported on 85%-95% of possible users it is good
for nothing - if we are talking of the native "name" property in
function object. This property is a proprietary extension in Gecko.

Similar functionality can be emulated cross-UAs though by using
toString/parsing if toString is not overriden. So if put theoretically
as "would be such property useful if available?" then yes - sometimes;
say for serializations.

Reply to this Message

-Lost - 28 Jan 2007 04:42 GMT

>> What in the world is functionName.name good for?
>
> Given that it is not supported on 85%-95% of possible users it is good
> for nothing - if we are talking of the native "name" property in
> function object. This property is a proprietary extension in Gecko.

Oops, I guess I missed that part. I was desperate to find a way to get *just* the
function name instead of the entire load that arguments.callee returns.

I found out that attempting to snag some of the data via substring was not going to work.
When I ran across that in the Core JS 1.5 reference I thought it would be the definitive
solution.

> Similar functionality can be emulated cross-UAs though by using
> toString/parsing if toString is not overriden. So if put theoretically
> as "would be such property useful if available?" then yes - sometimes;
> say for serializations.

What is a "UA"?

-Lost

Reply to this Message

Osmo Saarikumpu - 28 Jan 2007 16:20 GMT

> What is a "UA"?

That would be an User Agent, a.k.a browser.

Signature

Osmo

Reply to this Message

Spartanicus - 28 Jan 2007 16:54 GMT

>> What is a "UA"?
>
>That would be an User Agent, a.k.a browser.

A browser is a UA, but not all UAs are browsers. Any application that
can process HTML is a HTML UA, for example a SE bot, a validator etc.

Signature

Spartanicus

Reply to this Message

-Lost - 28 Jan 2007 17:13 GMT

>>> What is a "UA"?
>>
>>That would be an User Agent, a.k.a browser.
>
> A browser is a UA, but not all UAs are browsers. Any application that
> can process HTML is a HTML UA, for example a SE bot, a validator etc.

Thanks you two.

-Lost

Reply to this Message

Elegie - 28 Jan 2007 10:46 GMT

Hi,

Agreed for the cross-browser argument, however were 'function.name'
available to other user agents, would the conclusion still remain : it
is, by essence, a useless feature in (modern) javascript.

When conceptualizing functions, one should consider that they are by
nature anonymous objects, which can be bound to zero or many named
properties of any object. In other words, functions can be anonymous
(not even declared on some named property), or have several "names".

The approach of manipulating functions by their name generally indicates
that the programmer is not aware that functions are first-class objects
in javascript; his/her scripting approach is incomplete and generally
results in some complicated and unnatural production.

<URL:http://en.wikipedia.org/wiki/First-class_object>
<URL:http://en.wikipedia.org/wiki/First-class_function>

> Similar functionality can be emulated cross-UAs though by using
> toString/parsing if toString is not overriden.

function funcName(func){
var p=/function\s+(\w+)/.exec(func+"");
return p?p[1]:null;
}

... was the code Gosha Bine proposed in his late func.js.

> So if put theoretically
> as "would be such property useful if available?" then yes - sometimes;
> say for serializations.

Serialization is the process by which you transform some 'live' object
or execution context into some bytes or text, so that it can be saved
and/or safely transmitted to other programs. Inflating the serialized
code then permits to resume the execution.

In javascript, functions names would not be used in some serialization
process, because not only has the name nothing to do with the function's
object identity, but also nothing to do with the function object itself
(the name related to the object to which it belongs as a named property).

Regards,
Elegie.

Reply to this Message

Nickolay Ponomarev - 30 Jan 2007 14:33 GMT

> VK wrote:Hi,
>
[quoted text clipped - 11 lines]
> properties of any object. In other words, functions can be anonymous
> (not even declared on some named property), or have several "names".

Wrong - function may or may not be anonymous. Though, you're right
that the 'name' of the function has nothing to do with the variable or
property it is assigned to.

In Mozilla source you can often see declarations like this:
var obj = {
//...
method1: function obj_method1() {
}
};

..which creates a named function 'obj_method1' and assigns it to
obj.method1. Now while is it true that one could assign the same
function to another property on another object, like so:
obj2.anotherMethod = obj.method1

..in reality this is seldom done (for certain kinds of functions
anyway).

Giving names to functions in such a way is useful for debugging:
* you can print sensible names in stack traces
* I believe Venkman uses function names when printing profiling data.
* When you want to add logging to a function that takes a function as
a parameter.
and so on.

> In javascript, functions names would not be used in some serialization
> process, because not only has the name nothing to do with the function's
> object identity, but also nothing to do with the function object itself
> (the name related to the object to which it belongs as a named property).

Either I misunderstood you or you are wrong. The function name
obviously has to do with the function object itself.

Nickolay

Reply to this Message

Elegie - 30 Jan 2007 16:48 GMT

Nickolay Ponomarev wrote:

Hi,

[In all this discussion I will be referring to the ECMAScript
specification, chap. 13, which describes accurately how functions work
in javascript]

>> When conceptualizing functions, one should consider that they are by
>> nature anonymous objects, which can be bound to zero or many named
[quoted text clipped - 4 lines]
> that the 'name' of the function has nothing to do with the variable or
> property it is assigned to.

I'm afraid we do not understand each other. Let me rephrase my
statement: in javascript, functions have no name, and using the
expression "function's name" is by nature incorrect, some kind of
language abuse, which may be useful, but also may slow down the
programmer in understanding that functions are first-class objects.

The thing is that what is perceived as the 'name' of the function is
generally (see below for the exception) the name of the property to
which this function is bound. Consider the following productions
(ECMA262 13).

---
function foo(){}
---

---
var bar=function(){}
---

According to the specification (excluding function joining issues), this
statement creates a function object (ECMA262 13.2), then creates a
property on the current Variable Object (be it the Global Object or some
Activation Object), then assigns the function to this named property. In
itself, the function has absolutely no name, it is simply some anonymous
callable object attached to the 'foo'/'bar' property of the Variable Object.

The only exception to this algorithm concerns the production
[FunctionExpression : function Identifier], which you have indeed used
as an example in your post. This pattern inserts an anonymous object in
the function's scope chain, with the identifier being defined as the
only property of this object; this results in the function being able to
call itself recursively (the identifier does not leak outside, as per
scoping rules).

Your considering this identifier as the function name does probably no
harm as long as you are aware of the exceptional aspect of this pattern,
but note that it is never used in cross-browsers projects, for IE does
not respect the ECMA specification with the quoted scoping rule.

This is getting rather theoretical, so to illustrate the whole point I
would like to ask the question: is the following examples, what is the
'name' of the function?

---
var foo=function(){}
var bar=foo;
---

or

---
function foo(){}
var bar=foo;
---

or

---
var foo=function bar(){}
---

or

---
(function(){
alert("Hello, World !");
})();
---

<snip>

> Giving names to functions in such a way is useful for debugging:
> * you can print sensible names in stack traces
> * I believe Venkman uses function names when printing profiling data.
> * When you want to add logging to a function that takes a function as
> a parameter.
> and so on.

I agree of course, I'm not arguing against defining an identifier in a
function at all :)

By the way, coding practices should not be adopted because of
tools/debuggers capabilities, but because it fits the paradigm of the
language (at first).

>> In javascript, functions names would not be used in some serialization
>> process, because not only has the name nothing to do with the function's
[quoted text clipped - 3 lines]
> Either I misunderstood you or you are wrong. The function name
> obviously has to do with the function object itself.

The only case when this matters is the FunctionExpression pattern, with
some defined identifier, as described above.

Also, serialization is a process in which an object's identity is
fundamental; a function 'name' as you see it, if optional, could
therefore not be used as identity trait, but rather as an informative
property. The following is perfectly valid in javascript, with
absolutely no name collapsing:

---
var bar1=function foo(){}
var bar2=function foo(){}
---

Regarding serialization is javascript, my statement was somehow purely
theoretical though, given the scoping rules some appropriate process
would probably include the whole global execution context.

Regards,
Elegie.

Reply to this Message

Nickolay Ponomarev - 31 Jan 2007 00:00 GMT

> Nickolay Ponomarev wrote:
>
[quoted text clipped - 17 lines]
> which this function is bound. Consider the following productions
> (ECMA262 13).

[snip]

> Your considering this identifier as the function name does probably no
> harm as long as you are aware of the exceptional aspect of this pattern,
> but note that it is never used in cross-browsers projects, for IE does
> not respect the ECMA specification with the quoted scoping rule.

Yeah, sorry for calling you wrong. From the ECMA-262 standpoint you're
right - the functions don't have any particular "name".

In SpiderMonkey implementation the optional "Identifier" part is used
to choose a name for the function, which can later be referred to as
fn.name. Since the thread is about |.name|, which is not part of
ECMAScript, I didn't realize you were talking just about the standard.

[snip]

> > Giving names to functions in such a way is useful for debugging:
> > * you can print sensible names in stack traces
[quoted text clipped - 9 lines]
> tools/debuggers capabilities, but because it fits the paradigm of the
> language (at first).

Yet, for better or for worse, they are adopted because of tools'
capabilities.

[snip]

Nickolay

Reply to this Message

Richard Cornford - 30 Jan 2007 22:53 GMT

Nickolay Ponomarev wrote:
<snip>

> In Mozilla source you can often see declarations like this:
> var obj = {
[quoted text clipped - 5 lines]
> ..which creates a named function 'obj_method1' and assigns it to
> obj.method1.

Unfortunately the well-known bug in JScript makes this a potentially very
bad idea. To illustrate:-

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body>
<script type="text/javascript">

var f;
var test = 'Global';

document.write(aFunction +'<br>');
/*
Outputs:-

function aFunction(){return test;}

- and that is a bit odd, as the function expression with the optional
Identifier has not yet been evaluated. You might expect that result
when there was a FunctionDeclaration further down the code (as that
would result in the creation of a function object during variable
instantiation).
*/

with({test:'Scope Chain'}){
f = {
x:function aFunction(){return test;}
};
}

document.write(f.x +'<br>');
/*
Outputs:-

function aFunction(){return test;}

- so the - x - property of - f - refers to a function the - toString -
method of which appears to be returning the function expression with
optional Identifier.
*/

document.write(aFunction +'<br>');
/*
Outputs:-

function aFunction(){return test;}

- so a global - aFunction - refers to a function the - toString -
method of which appears to be returning the function expression with
optional Identifier. This may suggest a leaking of the Identifier -
aFunction - into the containing scope, but the next tests demonstrate
that that is not the case here.
*/

document.write((aFunction == f.x)+'<br>');
/*
Outputs:-

false

The function object referred to by a global - aFunction - is _not_ the
same function object as referred to by the - x - property of - f -.
There appear to be _two_ function objects here.
*/

/*
These tests demonstrate one of the consequences of this JScript bug.
When called the function objects attempt to resolve the Identifier -
test -. They do that against there respective scope chains and each's
Variable object does not have a - test - property so if it is resolved
it will not be as a property of the Variable object. If they come up
with different result there must be two distinct functions objects,
with two different scope chains.

There are two candidate - test - properties, a global - test -
property with the value "Global", and a - test - property on the
object added to the scope chain of function created with the
fucntion expression through the use of a - with - statement.
*/
document.write(f.x()+'<br>');
/*
Outputs:-

Scope Chain

- so the function object referred to by the - x - property of - f -
appear to be the result of evaluating a function expression within
an - with - statement, as the object added to the execution
context's scope chain with the - with - statement is on the scope
chain of the resulting function object (as expected).
*/

document.write(aFunction()+'<br>');
/*
Outputs:-

Global

- so the function object referred to by - aFunction - does not
have any object with a - test - property above the global object.
*/

</script>
</body>
</html>

The most comprehensive hypothesise that explains this behaviour is that
when JScript looks for FunctionDeclarations it uses a rather crude method
(probably for speed) but unfortunately it sees all FunctionExpressions
with optional Identifiers as FucntionDeclarations, but does so in a way
that does not prevent them from later being evaluated as
FunctionExpressions. The result is that every FunctionExpression with
optional Identifier causes a function object to be created during
variable instantiation (and assigned to a property of the Variable object
under a name that corresponds with the Identifier, and then, if
evaluated, a second function object is created. These two function
objects contain the same body code, but they differ in all the ways that
would be expected as a result of their differing contexts of creation.

Just to throw a little more confusion into the picture there is another
bug in JScript's handling of FunctionExpressions with optional
Identifiers. While the optional Identifier should result in an object
being added to the scope chain prior to the creation of the function
object, and a property added to that object with a name that corresponds
with the Identifier, and eventually a reference to the function object
assigned to that property. This does not happen in JScript, and so if the
code in the function body attempts to resolve the Identifier that was
used as its name it will be resolved as the function object resulting
from JScript treating the FunctionExpression as a FunctionDeclaration.
That means that if code in the function object that did result form the
evaluation of the function expression attempts to call itself using its
'name' it will actually be calling the other function object (which may
have another scope chain).

<snip>

> Giving names to functions in such a way is useful for
> debugging:
[quoted text clipped - 4 lines]
> a function as a parameter.
> and so on.

<snip>

That may help in debugging JavaScript(tm), in JScript it is going to be a
possible cause of extremely difficult to track down bug. The upshot of
which is that it is not that good an idea when doing cross browser work
(so pretty much anything commercial) unless the programmer had a very
good idea of what is going on in both ECMA conforming environments and
those with common bugs (JScript). And when that level of understanding
has been achieved other debugging strategies will have been recognised to
negate any benefits of giving names to FunctionExpressions.

Richard.

Reply to this Message

Elegie - 31 Jan 2007 00:07 GMT

> Unfortunately the well-known bug in JScript makes this a potentially
> very bad idea. To illustrate:-

<snip>

Since function expressions with the optional identifier set were not
processed correctly in IE I would never use them, however I didn't know
the whole thing was related to how IE processes function declarations.
Quite an enlightening article, thank you for this excellent post, Richard.

Regards,
Elegie.

Reply to this Message

Nickolay Ponomarev - 30 Jan 2007 13:53 GMT

On Jan 27, 10:05 pm, "-Lost" <spam_ninjaREMOV...@REMOVEMEcomcast.net>
wrote:

> What in the world is functionName.name good for? That is:
>
> function functionName() { return functionName.name; }
>
> I mean, I already had to write out the function's name so it seems that it is not very
> useful or efficient.

You forget that functions are objects in JS; you can assign them to
variables, pass as parameters to arguments.

> To me, this.name seems most appropriate, but of course that does not work within the
> context of a function unless defined as a class, which of course then the name property
[quoted text clipped - 3 lines]
>
> function functionName() { this.name = arguments.callee.name; }

Ugh, it looks like you should read about |this|. The JS reference on
developer.mozilla.org has good articles about it.

> But anyway... my original question, what is the purpose of using functionName.name as
> opposed to arguments.callee.name? (The second being useful, efficient and dynamic.)

arguments.callee is a function, so arguments.callee.name invokes the
same code that functionName.name. Of course getting the function name
via .name when you already know it doesn't make any sense.

Nickolay

Reply to this Message

Webmaster Forum / HTML, CSS, Scripts / JavaScript / January 2007

arguments.callee.name vs. functionName.name?