My example is not error-prone. You just don’t understand functions.
this is not personal, if you feel it is a personal rant, it is not. It is just a frustrated dude who thinks he is the next #worldDominator vomiting words into a textbox.
I should advice everyone to look up your blog (I think it is yours) and read up on the really strong articles you have (I really mean this. I really like the topics you are addressing there and they are really well explained).
I think it is also safe to say that the examples you are using in this article are bad… They do to much, using type-coercion in an example of hoisting simply adds to the confusion. That same example in fact demonstrates that hoisting really is: moving a var statement to the top of the function block. You should emphasize that.
I am also not at all convinced of your JS-knowledge, but it is hard to say something about that from one article - or comment.
##Default return values
Functions always return a value. Always. If no return; is used, then the default value returned is undefined. If you use the new keyword, the default value returned is this.
Writing:
function Person() {};
var p = new Person();
Is the same as:
function Person() { return this; }
var p = Person();
Using your approach doesn’t really fix anything, unless developer laziness counts as a problem that should be solved with code. Even worse, it helps writing hard-to-read code. We have a keyword to help us, so let’s use it.
And no, I don’t need to declare my privateName in my example. But think of code-readability. Think of variables that are not passed in in the constructor. Think of creating a clean example that shows one thing and one thing only. My example is used to illustrate how to create private variables with public getters and setters.
##Hoisting, var, function and var function
You kind of make a point, but kind of miss the point as well when you talk about hoisting and stuff. In JavaScript all variables and function declarations are hoisted, simply put (as you correctly state) they are moved to the top of the current function block.
function foo() {
console.log(a); //undefined
var a = 5;
}
foo();
Is actually parsed as:
function foo() {
var a;
console.log(a); //undefined
a = 5;
}
foo();//after the function exits, a is garbage collected since we no longer reference it
But what happens if we forget to declare our variable all together?
function foo() {
console.log(a); //undefined
a = 5;
}
foo();
This roughly translates to:
var a;
function foo() {
console.log(a); //undefined
a = 5;
}
foo();
Our variable a is declared globally, not because it is hoisted, but simply because we forgot to declare it, and so JavaScript declares it globally for us, the true friend he is.
And we now can no longer garbage collect our variable because it is global.
Then there is the difference between function declaration and function expression/statement. The first is hoisted, the latter not. But why is it hoisted? this has to with execution time. The JS-engine first parses our codezz and creates the execution context. This means declaring variables (and thus hosting them), parsing function declarations, … The next phase is execution. He simple walks over line by line and executes it.
//this is evaluated on execution-time
foo();
//the named function is created on parse-time, and thus hoisted
function foo() {
console.log('foobar');
}
The following however will not work:
foo();
var foo = function foo() {console.log('foobar');}
This because it translates to:
var foo; //the declaration of our variable is hoisted
foo(); //but it is still undefined here
foo = function foo() {console.log('foobar');} //here we assign a function expression to the variable.
Our function expression is only parsed on execution-time instead of parse time. #confusion ← this hashtag exists purely for JavaScript