modisposition

Once we have understood JavaScript Overload Patterns , a good start point to write efficient base classes, it comes natural to wonder about How To Override . First of all, please let me quote one of my favorite sentences from Mr D. I have been writing JavaScript for 8 years now, and I have never once found need to use an uber function. The super idea is fairly important in the classical pattern, but it appears to be unnecessary in the prototypal and functional patterns. I now see my early attempts to support the classical model in JavaScript as a mistake. Douglas Crockford, on Classical Inheritance in JavaScript Override In classical OOP, override means that a sbuclass can declare a method already inherited by its super class, making that method, the only one directly callable for each instance of that subclass. <?php class A { function itsAme() { $this->me = 'WebReflection'; } } class B extends A { function itsAme() { // B instances can acces

Quick post about a fast Function.prototype.bind implementation. Function.prototype.bind function bind(context:Object[, arg1, ..., argN]):Function { return a callback able to execute this function passing context as reference via this } In few words, if we have a generic object, we don't necessary need to attach a function to create a method: // a generic function function name(name) { if (name == null) return this.name; this.name = name; return this; } // a generic object var wr = {name:"WebReflection"}; // a callback with a "trapped" object var fn = name.bind(wr); alert([ // wr has not been affected wr.name, // WebReflection // fn can always be called fn(), // WebReflection fn("test") === wr, // true fn(), // test wr.name // test ].join("\n")); Designed to ensure the same context whatever way we decide to use the callback, included call, apply, setTimeout, DOM events, etc, Function.proto

Update I have continued with patterns into JavaScript Override Patterns . We all know JavaScript does not implement a native methods overload concept and what we usually do on daily basis is to emulate somehow this Classic OOP behavior. There are several ways to do it, all of them with pros and cons, but what is the best way to implement it? A common situation Let's imagine we would like to have a method able to accept different arguments types and return something accordingly with what we received. Usually in Classic OOP an overload cannot redefine the returned type but in JavaScript we can do " whatever we want ", trying to be still consistent, so that we can consider us more lucky than C# or Java guys, as more flexible as well. For this post, the behavior we would like to obtain will be similar to the one we can find in jQuery library, one of the most used, famous, and friendly libraries I know. // create an instance var me = new Person(); // set some property // vi

Every programming language has somehow defined its own standard to write code. To be honest, as long as code is readable, clear, and indented when and if necessary, I think we do not need so many "code style guides" and, even worst, sometimes these "code standards" let us learn less about the programming language itself, helping if we are beginners, sometimes simply annoying if we are professionals. Disclaimer This post aim is absolutely not the one to blame one of my favorite JS gurus, this post is to inform developers about more possibilities against imperfect automation we'll probably always find in whatever excellent spec we are dealing with. This post is about flexibility and nothing else! JSLint And Code Quality Wehn Mr D says something, Mr D is 99.9% right about what he is saying ... he clearly represents what we can define a Guru without maybe or perhaps but he, as everybody else here, is still a programmer, and we all know that every programmer

We have dozens of best practices to improve performances. We also have common practices to accomplish daily tasks. This post is about the most used JavaScript ArrayLike Object, aka arguments , and its performances impact over basic tasks. Why arguments While it's natural for JavaScripters to use such "magic" variable, as arguments is, in many other languages everybody knows it does not come for free and it is rarely used. <?php function myFunc() { // function call for each execution // rarely seen in good PHP scripts $arguments = func_get_args(); } ?> One clear advantage in PHP, Python, and many others, is the possibility to define a default value for each argument. <?php class UserManager extends MyDAL { public function exists($user='unknown', $pass='') { return $this->fetch('SELECT 1 FROM table WHERE user=? AND pass=?', $user, $pass); } } ?> This approach may brings automatically developers to code as

There is one single thing I don't like about CommonJS Idea , the fact nobody is thinking about the client side!!! CommonJS Why Since everybody would like to use JavaScript as Server Side Programing Language , where right now I can count there about 50 implementations, somebody decided that at least basic stuff such IO operations, streams or sockets, and much more, should have a common behavior, namespace, API, across all different implementations. In few words, these guys are trying to create their own WSW Consortium , and this is absolutely OK. So what am I complaining about? Client CommonJS If we, as developers and libraries authors, would have adopted a similar strategy ages ago, rather than fight with each other about natives prototypes pollutions, web development would be probably even easier for everybody. We failed, while those server side guys started correctly. The problem, for both language usage and its environment, is that JavaScript on server has different problems th