JAVASCRIPT functions knowing about other functions

Question

Is javascript code read from the top down?

In other words if I have:

function Color(){

}

function Weather() {

}

If I wanted to incorporate some type of weather object inside the Color function would it be possible since Weather is defined afterwards?

Doesn't matter, `Color` knows about `Weather` and vice versa — tymeJV, Jun 06 '14 at 02:03
JavaScript is read "top-down" but function declarations are *hoisted* constructs: see http://stackoverflow.com/questions/336859/var-functionname-function-vs-function-functionname (Otherwise, consider the difference between when the code is "read" and when the code is "evaluated".) — user2864740, Jun 06 '14 at 02:06
The code is entirely "parsed" before any of it is "run" so all top-level function declarations like `function xxx() {}` are known at execution time. — jfriend00, Jun 06 '14 at 02:10

score 3 · Accepted Answer · answered Jun 06 '14 at 02:15

The function Color won't know about Weather as it's being parsed, but it will once it is called. For example:

// Since variable declarations are hoisted to the top,
// myVar will be undefined (same as simply saying "var myVar;")
console.log(myVar); // <-- undefined
var myVar = 5;
console.log(myVar); // <-- 5

// test2 hasn't been defined yet, but it doesn't matter
// because test isn't being executed
var test = function() {
    test2();
}

// This will throw an error: undefined is not a function
// because test2 isn't defined
test();

var test2 = function() {
    alert("test2");
}

// This won't throw an error
test();

Essentially, you should execute after all functions have been defined. However, if you use the function functName() {} syntax, then it is hoisted just like a var statement.

function test() {
    test2();
}

// Works!
test();
function test2() { alert("test2"); }

Why are you spending most of the time talking about the `var x = function() {}` declaration construct that the OP is NOT using? — jfriend00, Jun 06 '14 at 02:27

score 1 · Answer 2 · edited May 23 '17 at 10:26

JavaScript is parsed "top-down" and Function Declarations are hoisted constructs - see var functionName = function() {} vs function functionName() {}. Parsing happens before the JavaScript execution itself starts; the following thus covers the evaluation semantics¹.

Given the effect of function hoisting, the following code is valid, although it seems like it might not be:

function a(){
    return b();
}
alert(a()); // alerts "b", even though "b comes later"

// This declaration IS hoisted
function b() {
    return "b";
}

However, considering that even when using "var fn = .." (when the assignment is not hoisted) the ordering usually doesn't matter because the evaluation of the assignments happens before the usage:

var a = function () {
    return b();
}
// alert(a()); <- this would fail, because b is not assigned yet

// This assignment is NOT hoisted
var b = function () {
    return "b";
}

// But b is assigned before here, meaning that the order of the constructor
// functions still Just Doesn't Matter.
alert(a());

As such, in the case where there are two constructor functions (e.g. Color and Weather) which are [mutually] dependent, it doesn't matter where they are located in the same scope relative to each other.

¹The thing that matters is the expression representing the dependency is resolvable when evaluated (which is relative to the evaluation code, but not related to the parsing/placement order of the functions).

score 0 · Answer 3 · answered Jun 06 '14 at 02:11

so basically yeah you can implement something to a function that appears in a previous code. hole this helps you understand it better.

    var weather = function() {
    if (weather === red) {
    console.log("weather is represented by the color red");
    }
    else {
    console.log("Not the right color");
    }
    };
    weather(red);

JAVASCRIPT functions knowing about other functions

3 Answers3