Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > arguments.callee.name vs. functionName.name?

Reply
Thread Tools

arguments.callee.name vs. functionName.name?

 
 
-Lost
Guest
Posts: n/a
 
      01-27-2007
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 With Quote
 
 
 
 
VK
Guest
Posts: n/a
 
      01-27-2007
> 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 With Quote
 
 
 
 
-Lost
Guest
Posts: n/a
 
      01-28-2007
"VK" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
>> 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 With Quote
 
Elegie
Guest
Posts: n/a
 
      01-28-2007
VK wrote:

Hi,

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


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 With Quote
 
Osmo Saarikumpu
Guest
Posts: n/a
 
      01-28-2007
-Lost wrote:

> What is a "UA"?


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

--
Osmo
 
Reply With Quote
 
Spartanicus
Guest
Posts: n/a
 
      01-28-2007
Osmo Saarikumpu <(E-Mail Removed)> wrote:

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

--
Spartanicus
 
Reply With Quote
 
-Lost
Guest
Posts: n/a
 
      01-28-2007
"Spartanicus" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Osmo Saarikumpu <(E-Mail Removed)> wrote:
>
>>> 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.
>
> --
> Spartanicus


Thanks you two.

-Lost


 
Reply With Quote
 
Nickolay Ponomarev
Guest
Posts: n/a
 
      01-30-2007
On Jan 27, 10:05 pm, "-Lost" <(E-Mail Removed)>
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
> does not apply to the calling function.
>
> Of course, you could always assign it yourself like:
>
> 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 With Quote
 
Nickolay Ponomarev
Guest
Posts: n/a
 
      01-30-2007
On Jan 28, 1:46 pm, Elegie <(E-Mail Removed)> wrote:
> VK wrote:Hi,
>
> >> 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.

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

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 With Quote
 
Elegie
Guest
Posts: n/a
 
      01-30-2007
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
>> 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.


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


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 With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments