modisposition

In all its " sillyness ", the CoffeeShit project gave me a hint about the possibilities of an overloaded in operator . The Cross Language Ambiguity In JavaScript, the in operator checks if a property is present where the property is the name rather than its value . "name" in {name:"WebReflection"}; // true However, I bet at least once in our JS programming life we have done something like this, expecting a true rather than false . 4 in [3, 4, 5]; // false // Array [3, 4, 5] has no *index* 4 The Python Way In Python, as example, last operation is perfectly valid! "b" in ("a", "b", "c") #True 4 in [3, 4, 5] # True The behavior of Python in operator is indeed more friendly in certain situations. value in VS value.in() What if we pollute the Object.prototype with an in method that is not enumerable and sealed? No for/in loops problems, neither cross browsers issues since if it's possible in our target ...

just a quick post about ES5 Object.create performances. While in More ES5 Friendly Patterns paragraph I have described how to use new ES5 features to create instances in a better way, I have never tested directly performances against classic ES3 pattern. The Benchmark Logic Pretty simple, create a new object with a " privileged property " plus an inherited one. The test prototype looks like this object: var proto = {toString:function () { return this.name; }} The assumption is that somehow the object should be able to return it's name, which is not shared via prototype. ES3 Game I hope I don't have to explain this piece of code: function F(name) { this.name = name; } F.prototype = proto; To test above classical pattern, all we need is to confirm this behavior: var o = new F("instance"); alert(String(o) === "instance"); ES5 Game Using an updated browser, it should be possible to replicate ES3 behavior via this piece of code: var o = Object....

When a function is to be invoked immediately, the entire invocation expression should be wrapped in parens so that it is clear that the value being produced is the result of the function and not the function itself. I have already commented the popular JavaScript Code Convention article, but latest cited sentence is probably the only one I have never been sure about. Why Bother Actually, I have always found the expression: var something = function(){ // do stuff // return something }(); // invoke kinda enough to invoke inline a function expression. Somebody argued that above style is ambiguous. Since an inline invoke could be performed against a massive function body, the point is that we may need to scroll 'till the end of the function expression to know if it has been executed or not. In my opinion, whenever there is a function expression, we should always check the end of this function or we'll never be sure about the assigned value. Fair enough, even if the fun...

In JavaScript we mainly have two type of variables: primitives (string, number, boolean, null or undefined) object related (Array, Object, Function, unknown for IE) Due to this difference, a primitive string and a new String are two different worlds: var s1 = "abc"; var s2 = new String("abc"); s1 instanceof String; // false s2 instanceof String; // true The nature of primitive constructor is to return a typeof constructor, but if we use new in front of the same constructor, it will obviously return an instance of that constructor. This is the nature of javascript, summarized in this snippet: function I1(){ return 1; }; function I2(){}; var i1 = new I1(); var i2 = new I2(); In both cases, o1 and i2 will be respectively an instanceof I1, and I2. In few words, if a function is caled via new , the assigned value will be an instance o the constructor itself or, if it returns an instanceof Something , the instanceof something value. function I3(){ return n...