... I won't write any introduction, but I'll let you comment, OK?
for loops (plus ++i)
for(i = 0; i < 10; i++){}
// global i defined
for(var i = 0; i < something.length; i++){}
// cache the length if it won't change during the loop
// associate once only under certain conditions to speed up
for(var i = 0; i < 10; ++i) {}
// there is absolutely nothing wrong in above loop
Few people told me something like: "
doode, if you use ++i at the end you need to write i < 11 'cause i will be 1 inside the loop" ... basically the for loop has been rarely understood, let me try again:
// directly from C language, 1972
for(
// optional inline declaration, coma accepted for more vars
;
// optional condition to verify
// if undefined, it loops until a break is encountered
// this condition is performed BEFORE the first loop
// if false, the loop will never be executed
;
// optional POST operation, it will never be executed
// if the condition is false, "", 0, or null
// it is executed in any case AFTER the loop, if any
){};
// example
for(var i = 0; i < 1; ++i){
// one single execution
// i will be 0 here
};
// i will be 1 here
The reason ++i is preferred over i++, whatever Google
go language decided about it, is that i++ and ++i are totally different and you need to understand when, or why, you need i++ or ++i.
While ++i increments directly the variable, returning the variable itself, if numeric, i++ returns a NEW variable with the precedent value AND it increments the i var as well.
Pure JavaScript Example
function Num(value) {
this.value = value;
};
Num.prototype.valueOf = function () {
return new Num(this.value);
};
Num.prototype.toString = function () {
return "" + this.value;
};
var a = new Num(0);
var b = a++;
alert(a); // 1
alert(b); // 0
alert(a == b); // false
// again
var a = new Num(0);
var b = ++a;
alert(a); // 1
alert(b); // 1
alert(a == b); // true
It does not matter if speed speaking, the difference is "not that consistent", it matters that we are programmer, and if two things mean different things, we want to understand them, am I wrong?
Already defined variables, and scopes
Another piece of code you can find around the net, is this:
// something defined globally
var num = 1;
(function () {
// try to set a default
var num = num || 0;
})();
Above code will never work, and it's the ABC about scope and functions.
It's exactly like this:
// something defined globally
var num = 1;
(function (num) {
// now try to find the global num without this. or window. ...
})();
Same is for arguments:
function A() {
// this is actually correct since arguments shares same scope
// no shadowing in this case, thanks to qfox
var arguments = arguments || [];
};
What we need to understand, is that next code is ALWAYS true:
var u = 123;
(function () {
var u = (typeof u === "undefined");
// u is TRUE!!!
})();
The moment we define a scoped variable, it has precedence over whatever outer scope: bear in mind!!!
new Array, new Object
I can't wait the day people will stop to prefer this code:
var a = new Array(); // NOTE: no length/elements specified
var o = new Object(); // NOTE: no object to wrap/convert
rather than:
var a = [];
var o = {};
There are no excuses at all. First of all, the "new Array/Object" way is
unsafe, since both constructors can be easily redefined/wrapped, as explained ages ago in many different security related JavaScript issues.
Moreover, we have both
more bytes to digest and
reduced performance, and a compiler/minifier that is so cool that will change automatically new Array into [] will simply potentially
break our code so we cannot even rely improvements with production code.
So ...
PLEASE DON'T!
... and new Function ...
Hey,
Java guys, please answer this question:
Would you ever use in your Java life a factory method via "new" ???Seriously, I don't get it ... let's go one step back ...
The Meaning of Factory
The essence of the Factory Pattern is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."
JavaScript Functions Behavior
If a JavaScript function returns a
primitive value such: "string", true, false, null, int, double,
new function will return an
instanceof that
function, overriding the returned result.
Same is for no returns, or return undefined.
If a JavaScript function returns an
object, the usage of
new is completely
redundant and useless.
Array, Function, Object, and RegExp are Factory!!!
var a = Array();
var b = new Array();
var c = [];
[
a instanceof Array,
b instanceof Array,
c instanceof Array
]; // true,true,true
Boolean, Date, Number, and String are both primitive casts and Object constructors!!!
var a = 1;
var b = Number("1");
var o = new Number(1);
a === b; // true
a === o; // false
a == o; // true
a instanceof Number; // false
o instanceof Number; // true
typeof a; // number
typeof o; // object
As summary, and again, please repeat with me:
If a JavaScript function returns a primitive value such: "string", true, false, null, int, double, new function will return an instanceof that function, overriding the returned result.
If a JavaScript function returns an object, the usage of new is completely redundant and useless.
new Class(whatever) === new Factory(whatever)!!!
This is the most misunderstood part that seems so logical but does not make sense at all. 99.9% of cases and in different libraries we can find the classic call to
new Class to create what people think is a
Class in JavaScript (in few words, to populate the prototype of a runtime created function).
Wait a second ... did I just say:
to create a Class?
Uhm ... so, we don't create an instance ... we create a class ... uhm again, so, we are using a Factory, isn't it? :zizi:
Function.createClass() would be hundreds of times more correct, logically speaking, but we all like the new Class, right?
Well, I wonder how many Java Gurus create they Java classes via new Class() on daily basis ... what? You have to define a class, not to create one? ... oh, REALLY???
MooTools use new Class to create runtime functions, parse the configuration object in order to populate the created function prototype, extending it with a completely useless
this, that could be simply Class.prototype without useless runtime instanc`es creation for each Class, to finally return a function that
is not instanceof Class ... not even primitives values in JavaScript are that ambiguous, isn't it?
new Class({}) instanceof Class; // FALSE!!!
MooTools is simply one in the ocean of libraries that use this misconception to create
Functions, not Class, Function.
Considering that JavaScript has no classes, something apparently unacceptable for GWT and friends maniacs that absolutely need to compile their Java application inevitably into a prototypal based programming language as JavaScript is, thinking they have more power over the application, I agree that classic OOP is something so intrinsic in the IT panorama, that it will never die and it could make somehow things simpler for newcomers into JavaScript. OK, I am with you ... can we at least agree about the fact new factoryMethod does not make sense at all?
Logically Speaking ...
Rather than nonsense why don't we simply respect JavaScript native behavior?
If we consider native constructors behaviors such Boolean, Number, or String, I have already described what's up if we use new or not.
There is a massive difference between new and not new ... so why don't use the same behavior for Funciton?
// example
var f = Function("return 'function'");
alert([f instanceof Function, f()]);
// true,function
var f = new Function({toString:function(){return "instance"}});
alert([f instanceof Function, new f()]);
// true,instance
In few words we can easily think about Function as a primitive function creator AND as a function instances creator, those that we'll love to use to instantiate our application objects. Does it sound really that silly?
var Function = (function (Function) {
// (C) WebReflection Mit Style
// Class with private constructor
function constructor(constructor) {
function Class() {
constructor.apply(this, arguments);
};
return Class;
};
// Class creator
function Class(__proto__) {
function Class() {};
if (__proto__) {
if (hasOwnProperty.call(__proto__, "constructor")) {
Class = constructor(__proto__.constructor);
};
(Class.prototype = clone(__proto__)).constructor = Class;
};
return Class;
};
// special Function
function $Function(arguments, body) {
return this instanceof Function ?
Class(arguments) :
body == null ? Function(arguments) : Function(arguments, body)
;
};
// private variables
var
hasOwnProperty = Object.prototype.hasOwnProperty,
clone = Object.clone || (function () {
function clone() {};
return function (__proto__) {
clone.prototype = __proto__;
return new clone;
};
})()
;
// public static explicit factory
$Function.create = Function;
$Function.createClass = Class;
$Function.prototype = Function.prototype;
return $Function;
})(Function);
Here we are, and the best thing is that we can extend the prototype chain simply passing another prototype as configuration object.
function A(){};
var B = new Function(A.prototype);
alert(new B instanceof A); // true
Moreover, since whatever library will use a Function to create other functions, but since most of the time the new Class won't return an instanceof Class, with my suggestion whatever created "Class" will simply inherit Function.prototype.methods OR, if we want to add custom public methods, we can always do it later.
Finally, with a simple closure, we can still be semantic, and define private methods:
var MyClass = new Function((function () {
function set(value) {
this.value = value;
};
return {
constructor:function (value) {set.call(this, value)},
get:function () {return this.value}
};
})());
var o = new MyClass(123);
alert(o.get()); // 123
Now it's your turn, feel free to comment the path I followed, and give me other suggestions/common errors, if you remember any ;)
Update I almost forgot one of the most famous/silly one ...
Arrays "for in"
var a = [];
a[1] = 1;
a[0] = 0;
// global key defined
for(key in a);
// key will be first 1, then zero, in Internet Explorer and Opera
for(var key in a);
Another common mistake is to think that "for in" is good for arrays.
First of all
the iteration order is unpredictable, there is no rule about "for in" iteration (or if any, nothing that is standard, cross-browser speaking) plus it's way
slower than a normal iteration via length. Please DON'T!!! In this case as well.
