[Bug 626] New: Function definition does not overwrite variable definition

http://helma.org/bugs/show_bug.cgi?id=626

           Summary: Function definition does not overwrite variable
                    definition
           Product: Helma
           Version: CVS trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P1
         Component: JavaScript Interpreter
        AssignedTo: helma-dev@...
        ReportedBy: interface@...


The following code (if defined in global context) leads to an -- at least for
me -- unexpected result by giving the first definition of the variable "foo"
precedence to the second definition of the function "foo":

var foo = function() {
   return "This is: var foo = function()";
}

function foo() {
   return "This is: function foo()";
}

Root.prototype.main_action = function() {
   res.write(foo());
}

Expected result:
This is: function foo()

Actual result:
This is: var foo = function()

I tested the same code in Firefox and it actually behaves the same. (WTF!?)

However, I don't understand this behaviour at all and consider this a bug
unless someone can explain it thoroughly. A pointer to a comprehensive source
might do the trick as well.


--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

http://helma.org/bugs/show_bug.cgi?id=626


maksim.lin@... changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #1 from maksim.lin@...  2008-09-02 01:37 -------
This looks like its due to the differences between function declarations and
function expressions.

Perhaps this (about half way down the page) sheds some more light:
http://developer.mozilla.org/En/Core_JavaScript_1.5_Reference:Functions#Function_constructor_vs._function_declaration_vs._function_expression

So I think why this happens is that the function declaration:
function foo() {
   return "This is: function foo()";
}

happens when the script is parsed while the function expression:
var foo = function() {
   return "This is: var foo = function()";
}

happens *afterward* when the script *runs* hence the assignment of the function
to the variable foo happens after the function declaration which named the
function "foo" in the global scope.

Tricky stuff!!!!!!!
I would never have thought of this with out looking it up myself

Another good explanation can be found in:
http://www.jibbering.com/faq/faq_notes/closures.html
(the relevant section is: "Identifier Resolution, Execution Contexts and Scope
Chains" and the subsection "The Execution Context".


--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

http://helma.org/bugs/show_bug.cgi?id=626





------- Comment #2 from breton.slivka@...  2008-09-02 02:51 -------
I agree in principle that it's by design, but not quite in the details. The
unexpected behavior in this bug is due to something javscript has called
"hoisting". What happens is that function definitions get automatically and
transparently moved to the top of the scope (whether that's global scope, or a
function scope), and variable declarations (but not their assignments) get
moved to the top of the scope, just underneath the function definitions.

So if I understand this correctly, this bit of code in the bug

var foo = function() {
   return "This is: var foo = function()"; }

function foo() {
   return "This is: function foo()";
}

Root.prototype.main_action = function() {
   res.write(foo());
}



Gets translated before it's executed into:


function [anonymous1] (){
   return  "this is: var foo = function()"; }

function foo() {
   return "this is: function foo()";
}

function [anonymous2]() {
  res.write(foo());
}

var foo;
foo = [anonymous1];
Root.prototype.main_action = [anonymous2]


So as you can see since after hoisting, the variable assignment gets moved
after the function declaration, it takes precedence.


--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

http://helma.org/bugs/show_bug.cgi?id=626


interface@... changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |VERIFIED




------- Comment #3 from interface@...  2008-09-02 12:32 -------
Thanks for the clarifications to both of you.

I just went through Crockford's "Good Parts" again – "hoisting" is not
mentioned in the index – and Crockford also explains the hoisting feature
(p.113, "The function Statement Versus the function Expression") and why he
favours the expression over the statement:

"This relaxes the requirement that functions should be declared before used,
which I think leads to sloppiness. It also prohibits the use of function
statements in if statements. It turns out that most browsers allow function
statements in if statements, but they vary in how that should be interpreted.
That creates portability problems."


--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev