modisposition

Few days ago I wrote a post about this argument , proposing an alternative "best option" way to use an injected parent in each method. As soon as more developers read my post, more sparkles came out from the fire: true classical inheritance simulation via missed methods in the chain, exception during methods execution that could trap the temporary injected parent, and other interesting stuff again. At the end of all these tests, benchmark, and libraries evaluation, I decided to step backward about my proposal, making things simple, logic, and extremely fast (as much as possible). My Conclusions if we inject a parent, we have to change and/or wrap the original method, adding noise in the execution and inevitably more operations to perform (read: less performances) for each inherited metod, even if it is the same of the parent one, we need to add functions and code which means more RAM and less portability more we over-mess the simple JavaScript inheritance stack, less control

receive emails from my PC or my Android send emails from my PC or my Android follow developers via mailing list via PC or Android chat via GTalk with buddies (mainly developers) Bloody Hell I feel outside the world!!! P.S. ... but fortunately in few minutes everything went back :D

You know ... sometimes in 2009 a dice based game could be an evening resolution or simply nice time to spend with somebody else. I was out of paper and after the second try to draw manually the Yahtzee table I though: Why on earth I do not create a table to play with? Here I am: Yahtzee! on line You can print in landscape and reuse the paper 4 times (two tables in the front, two in the back) or to be even more green, you can simply put your green laptop in the corner of the table and play with the interactive table. I usually play with F11 option (full screen browser), but I am not sure the automatic score is a good idea (more interesting to count manually who is winning, isn't it?) Have fun :)

Disclaimer This post is a reply to kangax question : I’m sorry but why such vicious coding style? I'd like to explain my point of view about JavaScript code style so, if interested, please read until the end, thank you :) Some Background I study and use JavaScript since year 2000 and one of the most interesting thing about this language is that even if it is "that old" you never stop to learn something new (techniques, strategies, adapted patterns, etc). At the same time, the " biggest trouble " of this language is its weight in a page, which is the reason we all use minified and gzipped or packed versions of our application. Coming from a " 33Kb modem internet era " I always tried to pay attention about the size and I studied and created both a JavaScript minifier and a compressor . Compressors Rules Unless we are not using an " incremental " compressor, as GIF is, we should consider that packer algorithm, as gzip and deflate , are dicti

Update: I have replied to myself and developers in a new post . I would like to say a big Thank You to every developer exposed tests, benchmark, traps, and considerations. Please read my last thoughts about the subject, since I deeply reconsidered my position. Update: Please do not get me wrong. I have no intention to say that one or any of cited framework, piece of code, library, is not good or fast enough to extend other classes. This post is about maniac optimization based on personal considerations over some deeper analysis to complete in a way the first benchmark. I am not criticizing libraries, they are great and they offer everything, I am simply showing a specific case, which is particular on purpose, and a specific behavior that, useful or not, could not be respected. About Few days ago Ajaxian published a post about JS inherited methods performances via common libraries strategies. I think the argument is extremely interesting but there's not enough material yet, so her

First of all one consideration: JavaScript is SLOW! Chrome, Safari, Opera, FireFox (Internet Explorer obviously is the only one 2 to 8 times slower!) It does not matter which tracemonkey or V8 you are using, JS is far away to be fast as C#, C++, C are! About Levenshtein If you would like to create a project like BJSpell with a reasonable suggestion , the levenshtein algorithm will trill at some point: it calculates the distance between 1 string to another one. It means that from the word "Gofy" to the word "Goofy", this algo will return 1 character to change replace, or add, before Gofy will become Goofy. Why Levenshtein To obtain a suggestion that makes sense, we could use some known algorithm to recognize at least words close to the mistyped one. So far, my suggestion in BJSpell was something truly rude and often useless, but as far as I know there is NO WAY to implement something more clever, using every possible best performances practice. How to speed up the

As I wrote months ago in this documentation about JavaScript prototypal inheritance , subclass native data type is not that simple (almost not possible at all) but since JS is loads of weird bits and bops, I often try to break its documented limits. It was the Array , some time ago, now it is about time for String. The concept is similar, if you subclass a native data type its methods will return that native data type like instance, so concat, charAt, toString, etc etc, will return a String unless we do not override every inherited method (so performances wont be that good). Subclassed String (function(Function, slice, push){ // from WebReflection: Subclassed String function String(String){ if(arguments.length) // clever constructor, accepts more than a string as argument push.apply(this, slice.call(arguments).join("").split("")); }; String.prototype = new Function; try{ (new String) + ""; // exception in FireFox var join = Array.proto

kangax as reply to Diego comment , then Ajaxian as desert with my comments, but three of us completely in the wrong direction. Why isNative? As I though and as Diego Perini confirmed, sometimes we would like to trust the environment itself before we act in a certain way. I wrote about an XMLHttpRequest wrapper for Internet Explorer, but cases are numerous, like a "not compliant" implementation of the Array.prototype.forEach, or others proto, or some injection problems about window.Array, window.String, or who knows what else. Accordingly, since the JavaScript nature is dynamic, widely dynamic, we would like to be sure that a method is as "specs says" rather than how this or that library implemented it. Can we trust an unreliable environment? The first error we all committed was to find the "best way ever" to understand if a function/method has been changed, without considering the fact that the function isNative itself could be a fake ! No matter how goo

We all like the jQuery code style where the instance is returned almost everywhere, but we often forget about DOM methods that do the same and ages before whatever library. I rarely spot some " returned instance " trick in daily posts or even famous libraries. Here a couple of example: // daily way ... var div = document.createElement("div"); document.body.appendChild(div); // easy way var div = document.body.appendChild(document.createElement("div")); // boring way var div = document.createElement("div"); div.appendChild(document.createTextNode("test")); document.body.appendChild(div); // funny way var div = document.body.appendChild( document.createElement("div") ).appendChild( document.createTextNode("test") ).parentNode ; ... on and on, there are several methods used on daily basis that do not consider returned values. So, why don't we like to use them? var el = document.createElement(

Introduction Nowadays, we read news about new libraries, technologies, etc etc, but there is an area in this Web 2.0 era which seems to be " stuck " since big G introduced AdSense : a new way to deliver advertisement, compatible with new devices such as Google Android and Apple iPhone . Even if Google proposes AdSense for mobiles as well, we know that those simple text boxes do not cope properly with Android and iPhone innovative web browsers. This is why I have though about a new way to show ads, unobtrusive, cross-browser, and in a way even funny, with less than 2Kb minified and gzipped code, library independent, with everything inside its own closure ;-) Ad 2.0 Introduction The iframe below perfectly represents my idea of mobile advertisement, idea that I will explain better a bit further down. Every 10 seconds, a little banner comes up at the bottom of the screen, and it persists for 2 seconds before it disappears. The number of bunners can be from 1 till unlimited, in

I found this post from Ajaxian extremely interesting, and I decided to try to create a better version, if it is possible, of Google Buttons 3.1 The result is not perfect, still alpha, and just for fun, but compatibility seems to be great while multiple buttons visualizations (horizontal or vertical) is extremely simple: write links beside each other, or add a couple of rules for vertical version. States are hover, active, selected, represented via JavaScript events (onmouseover, onmousedown, onmouseup). As I said this is just an experiment, but I think as is it is not that bad ... maybeI am wrong :D

Somebody asked me to implement a web based spell check without plug-ins or specific browsers requirement (we all know banks security policies, for example, every plug-in could be dangerous but maybe they are still using the most un-secure browser still available these days: Internet Explorer 6 ... ) My answer, straight on: Guys, there is nothing available in pure JavaScript, but I can investigate about it That's it, a couple of searches via Google , and nothing as expected ... but hey, wait a minute: what's about FireFox spell checker plug in and Open Office project? Here we are, Hunspell is the answer! BJSpell Project In a full day of self brain storming, history background cases study, and code, plus debug and tests, I created BJSpell , a basic, fast, cross browser, and runtime implementation capable to underline bad words using a pre compiled Hunspell compatible dictionary (one or more). The reason I avoided the usage of the classic " click here for the spell checke

I find the static keyword in PHP 5.3 absolutely useful, but I instantly felt into a dilemma: what about parent? With static it is possible to refer to a generic class static property, without referring the class where the method has been declared. Here there is a simple example: class Numbers { public static $value = 0; public static function getValue(){ return static::$value; } } class One extends Number { public static $value = 1; } class Two extends Number { public static $value = 2; } $one = new One; $two = new Two; $one->getValue(); // 1 $two->getValue(); // 2 Above example shows how static behaves when an instance calls a method which uses static keyword. Whatever subclass it is, we will always obtain the defined value (if any, otherwise the inherited one) as expected. But what about parent behavior? If we use parent inside a method it is like using self, the parent keyword will always refers to the parent class, if any, of the method which conta