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
[FunctionExpress ion : 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 FunctionExpress ion 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.
