modisposition

OK, OK, probably is just that I cannot wait to start writing stuff with [tinydown](https://github.com/WebReflection/tinydown#tinydown) but I tweeted about this after last #FlightNight and @angustweets demo ... so here what is behind [Flight](http://twitter.github.io/flight/) mixins choice. ### The Basics JavaScript polymorphism is probably one of the best things you can find out there. Not kidding, the flexibility that this language offers when it comes to context injection and runtime class definition is simply amazing, as simple, and amazing, is this idea: ```js // most basic example function enriched() { this.method = function () { // do stuff }; } ``` Most common books and online documents usually describe above example as a _constructor with privileged methods_. Well, that's actually what you get if you `var obj = new enriched();` but that's just one story. Flight uses a different story, offering alternative methods with better semantics but basically going down to...

I know it might sound boring but I really want to put everything down and laugh, or cry harder, the day TC39 will realize __proto__ was one of the most terrible mistakes. A Simple Dictionary Attack ES6 says that Object.create(null) should not be affected anyhow from Object.prototype . I've already mentioned this in the 5 Reasons You Should Avoid __proto__ post but I forgot to include an example. You can test all this code with Chrome Canary or Firefox/Nightly and the most basic thing you need to know is this: var n = Object.create(null); n.__proto__ = {}; for (var k in n) console.log(k); // __proto__ !!! Object.keys(n); // ["__proto__"] !!! Got it? So, __proto__ is enumerable in some browser, is not in some other but it will be in all future browsers. Let's go on with examples ... // store values grouped by same key function hanldeList(key, value) { if (!(key in n)) { n[key] = []; } n[key].push(value); } // the Dictionary as it is in ES6 var n = Object....

Symbols , previously known as Names , are a new way to add real private properties to a generic object. // basic Symbol example var BehindTheScene = (function(){ var symbol = new Symbol; function BehindTheScene(){ this[symbol] = {}; } BehindTheScene.prototype.get = function(k) { return this[symbol][k]; }; BehindTheScene.prototype.set = function(k, v) { return this[symbol][k] = v; }; return BehindTheScene; }()); var obj = new BehindTheScene; obj.set('key', 123); obj.key; // undefined obj.get('key'); // 123 In few words symbol makes possible to attach properties directly without passing through a WeakMap. A similar behavior could be obtained indeed via WeakMaps: // similar WeakMap example var BehindTheScene = (function(){ var wm = new WeakMap; function BehindTheScene(){ wm.set(this, {}); } BehindTheScene.prototype.get = function(k) { return wm.get(this)[k]; }; BehindTheScene.prototype.set = function(k, v) { return wm.get...

Update : when you've done with this post, there's even more in comments and the newer one: Yet Another Reason To Drop __proto__ Too many discussions without real outcome about __proto__ magic evilness or feature. It's time to understand why using it is, today , a bad idea. __proto__ Is NOT Standard (yet) TC39 refused to standardize this property because of the amount of problems it brings . Apparently will be part of ES6 but is not there yet. __proto__ is a silent, non spec'd, agreement. What's the problem? Keep reading ;) __proto__ Could NOT Be There The silent non standard agreement sees __proto__ as configurable property of the Object.prototype . As example, try this in some environment: (this.alert || console.warn)( delete Object.prototype.__proto__ ); // false or true ? The outcome is migrating from false to true . As example, current Chrome has a non configurable descriptor, while Canary has a configurable one. Same is for latest node.js, Firefox, an...

This (apparently non working) gist gave me the hint. Stuff I've been dealing with for a while , finally used to bring an Object.create(firstArgOnly) cross platform/engine/client/server code that works. The name? inherit() More Reliable Than Object.create() The reason I didn't even try to polyfill the ES5 Object.create() method is quite easy: it is not possible to shim it in a cross platform way due second argument which requires descriptors features, highly improbable to simulate properly. Even if browsers support the create() method, inherit() guarantee that no second argument will ever be used so we are safe from inconsistencies within the function. Forget hasOwnProperty ! Yeah, one of the coolest things about being able to inherit from null is the fact not even Object.prototype is inherited so we can create real empty objects without worrying about surrounding environment, 3rd parts obtrusive libraries, and the boring and slow obj.hasOwnProperty(key) check. // so...

it seems to me the most obvious thing ever but I keep finding here and there these common anti pattern: // 1. The timer Case this.timer = setTimeout( this.doStuff.bind(this), 500 ); // 2. The Listener Case (objOrEl || this).addEventListener( type, this.method.bind(this), false ); What Is Wrong I have explained a while ago what's wrong and how to improve these cases but I understand the code was too scary and the post was too long so here the summary: every setTimeout() call will create a new bound object and this is both redundant and inefficient plus it's not GC friendly there is no way to retrieve that listener created inline so it's impossible to remove the listener any time is necessary ... yes, even after, when you do refactoring 'cause you will need to clean up listeners What You Need The short version is less than a tweet, 64bytes: function b(o,s,t){return(t=this)[s="@"+o]||(t[s]=t[o].bind(t))} This is the equivalent of: // as generic prototy...