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 ...

In my latest posts I have talked about current situation for JavaScript " Classes ". In Good Old And Common JS Errors I have introduced a misconception of a generic "Class" function which is usually not able to produce instanceof Class , considering Classes in JS are functions indeed. In Better JS Classes I have explained how to write a meaningful Class factory , avoiding the _super pollution over each extended method, while in the JS _super Bullshit I have explained why the _super/parent concept does not scale with JavaScript prototypal inheritance model. More than a dev, Mr Crockford included, agreed that in JavaScript the classical pattern does not fit/scale/produce expected results, and even worst, it could cause "disasters" during a session and slow down overall performances (and about this topic I have already said that web developers should stop to test their stuff with powerful CPU, read Macs! Buy a bloody Atom based device as I have done and af...

I know you already hate the title, but that's how I called one paragraph of my precedent post: Better JavaScript Classes . This post is mainly dedicated for both libraries authors, and those Classic OOP Developers that still think JavaScript should be used in a classic way. _super or parent Are Problematic! It's not just about performances, where " the magic " may need to replace, wrap, and assign runtime everything in order to make it happens, it's about inconsistencies, or infinite loops, or hard debug, or disaster prone approach as well, since as I have already said instances have nothing to do with _super/parent .... so, how are things? Thanks for asking! Real OOP Behavior It's the ABC, and nothing else, if we call a parent/super inside a method, this method will execute with a temporary self/this context. This means that the instance will be still: an instanceof its Class only that method will be executed, it is possible to call other super/parent accord...

Update This post continues here, in the JavaScript _super Bullshit one. In my precedent post I have discussed about few common JavaScript errors, included the classic new Class() call to retrieve a runtime created function, populating its prototype. While my suggestion is both semantic and reasonable, I am pretty sure nobody on earth will ever implement that native Function wrapper , and this is the reason I am posting again, this time hopefully with a better suggestion. JavaScript Class Abstract Concept It's extremely hard to understand for those with classic OOP background but JavaScript has no Classes , just objects, where functions are first class objects but still objects! Assumed this, we can try in any case to think about a JavaScript Class as a " function which aim is to create instances of function itself ". What Is Wrong Right Now What I argued about in my precedent post is that this statement is too often unconsidered: // try with Mootools or some other libr...

PHP and operator overloading Not everyone knows that with PHP, and since 2006, it is possible to implement operator overloading, thanks to a PECL extension . One common PHP VS other language flame, is about PHP poor OOP expressiveness and power. Another common request from skilled PHP developers, is the possibility to create a class that is able to manage every situation during code execution. For example, try to think about a Number class, and try to use every native Magic method to perform a simple task like this one: $i = new Number(123); $i += 2; echo $i; // 125 Above code is simply not implementable with current version of PHP 5.2 or greater, if we do not install php_operator.so or .dll. Unfortunately, this extension is still experimental, and not documented at all. That is why I have created a full class, based entirely on this extension, and for this post only, compatible with PHP 5.2 (then, without usage of late static binding). The JavaScript like Number class Next code, is a...