arguments.callee.name vs. functionName.name?

Discussion in 'Javascript' started by -Lost, Jan 27, 2007.

  1. -Lost

    -Lost Guest

    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
     
    -Lost, Jan 27, 2007
    #1
    1. Advertising

  2. -Lost

    VK Guest

    > 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.
     
    VK, Jan 27, 2007
    #2
    1. Advertising

  3. -Lost

    -Lost Guest

    "VK" <> wrote in message
    news:...
    >> 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
     
    -Lost, Jan 28, 2007
    #3
  4. -Lost

    Elegie Guest

    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.
     
    Elegie, Jan 28, 2007
    #4
  5. -Lost wrote:

    > What is a "UA"?


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

    --
    Osmo
     
    Osmo Saarikumpu, Jan 28, 2007
    #5
  6. -Lost

    Spartanicus Guest

    Osmo Saarikumpu <> 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
     
    Spartanicus, Jan 28, 2007
    #6
  7. -Lost

    -Lost Guest

    "Spartanicus" <> wrote in message
    news:...
    > Osmo Saarikumpu <> 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
     
    -Lost, Jan 28, 2007
    #7
  8. On Jan 27, 10:05 pm, "-Lost" <>
    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
     
    Nickolay Ponomarev, Jan 30, 2007
    #8
  9. On Jan 28, 1:46 pm, Elegie <> 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
     
    Nickolay Ponomarev, Jan 30, 2007
    #9
  10. -Lost

    Elegie Guest

    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.
     
    Elegie, Jan 30, 2007
    #10
  11. Nickolay Ponomarev wrote:
    <snip>
    > 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.


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

    <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.
     
    Richard Cornford, Jan 30, 2007
    #11
  12. On Jan 30, 7:48 pm, Elegie <> wrote:
    > Nickolay Ponomarev wrote:
    >
    > >> 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).

    [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
    > > * 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).
    >

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

    [snip]

    Nickolay
     
    Nickolay Ponomarev, Jan 31, 2007
    #12
  13. -Lost

    Elegie Guest

    Richard Cornford wrote:

    > 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.
     
    Elegie, Jan 31, 2007
    #13
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jai hanuman

    caller / callee graph ...

    jai hanuman, Dec 16, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    683
    jai hanuman
    Dec 16, 2003
  2. Csaba  Gabor
    Replies:
    9
    Views:
    154
  3. VK
    Replies:
    7
    Views:
    229
  4. GTalbot
    Replies:
    3
    Views:
    112
    GTalbot
    May 28, 2010
  5. Replies:
    11
    Views:
    502
    Jeff Higgins
    Oct 10, 2012
Loading...

Share This Page