Posts

Showing posts with the label ECMAScript 5

The JavaScript typeof Operator Problem

TL;DR don't even try to normalize or shim newer typeof via code: you simply can't! Whenever it was a mistake or not to consider typeof null == "object" , many libraries that tried to normalize this operator failed to understand that null is not the only problem . The JS Polymorphism Nature We can borrow methods for basically everything but primitives values, such booleans, numbers, and strings, do not accept indeed any sort of property or method attached runtime. var s = "hello"; s.greetings = true; alert(s.greetings); // "undefined" However, we can still use methods through call() or apply() : function isGreetings() { return /^(?:ciao|hello|hi)$/.test(this); } alert(isGreetings.call("hello")); // true The only way to find a method in a primitive value is to extend its own constructor.prototype : String.prototype.isGreetings = function () { return /^(?:ciao|hello|hi)$/.test(this); }; alert("hello".isGreetings()); // tru...

ECMAScript 5 Full Specs String trim, trimLeft, and trimRight

During last evenings I have updated a little bit my vice-versa project . Since vice-versa aim is to bring in every browser what is possible to implement and, in most of the cases, already defined as standard (from W3 or MSDN when it is worthy) I decided to get rid of the Ariel Flesler fast trim proposal to introduce my lightweight full specs String.prototype.trim, trimLeft, and trimRight. For full specs I mean that vice-versa String.prototype.trim replace exactly same characters replaced by native Firefox 3.5 implementation, rather than only characters which code is less than 33 as is for Ariel proposal. The good part of vice-versa ( to be honest I cannot find bad parts so far ;) ) is that every single file is stand-alone, so if you do not like benefits the entire " lib " could bring, you can always adopt only one of its files, for example the String one, the Array one, or the last full specs ECMAScript 5 Date constructor , compatible with ISO strings, new Date("2009-0...

ECMAScript ISO Date For Every Browser

One most than welcome new entry of ECMAScript 5 is the Date.prototype.toISOString function and ability for Date constructor to accept an ISO String and to generate a Date instance. This feature will make JSON Date instances import/export extremely fast and simple, but why should we wait ES5 release when we can have both features now? Full Specs ISO 8601 Parser Plus Unobtrusive toISOString Method We all do not like that much to extend native JavaScript constructors, so here I am with a proposal that will not touch the Date prototype: if(!Date.ISO)(function(){"use strict"; /** ES5 ISO Date Parser Plus toISOString Method * @author Andrea Giammarchi * @blog WebReflection * @version 2009-07-04T11:36:25.123Z * @compatibility Chrome, Firefox, IE 5+, Opera, Safari, WebKit, Others */ function ISO(s){ var m = /^(\d{4})(-(\d{2})(-(\d{2})(T(\d{2}):(\d{2})(:(\d{2})(\.(\d+))?)?(Z|((\+|-)(\d{2}):(\d{2}))))?)?)?$/.exec(s); if(m === null) thr...

ES5 arguments and callee, I was wrong!

JavaScript is not JavaScript, I am not crazy, it is just a consideration between the language itself and what is behind it: another programming language with lower level rules and logic ... sounds silly and obvious, but please keep reading to understand what I mean. No Results Yet, But I've Already Lost My Battle I spread comments, I wrote post after posts to defend ECMAScript 5 arguments.callee decision with "use strict", but I have to admit I have never investigate the internal behavior of callee, an arguments property which is not what we think is ... Discovering In Core The Callee Property What I was thinking was something hilarious for a C or C++ programmer: an inherited property for a mutable instance. // JavaScript should have a "secret" Arguments class // and for each function, something like this function Test(){}; // we have declared the function Test // internally there should be a secret operation like this: Test._createArguments = function(args){...

Do Not Remove arguments.callee - Part II

Few days ago kangax demystified named function expressions , underling the importance of the read only function name property and how messy is Internet Explorer JScript engine with named function and their scope. Before that post, I wrote one about ECMAScript 5 decision to remove arguments.callee when "use strict"; is present (note in the link: it is not deprecated right now, it is an arguments property) How These Two Things Are Related While kangax post was more focused about possible leaks and unexpected functions definitions, I would like to grab more attention about what this problem will cause in tomorrow libraries and JavaScript usage. Removing arguments.callee, our code size, apparently faster in core thanks to this missed variable, will increase drastically and a big part of the beauty of JavaScript language will disappear with this callee decision. The Classic Configuration Object Problem How many libraries base constructors via configuration objects? jQuery Ajax ? ...

[ECMAScript 5] Do Not Remove arguments.callee !

Being subscribed in dunno how many developers mailing list, I completely forgot to follow up the arguments and arguments.callee discussion. Accordingly to this John post , is with extreme surprise that I am discovering how critical is the gap between programming language developers and programming languages active users. Even if I read more than once piece of SpiderMonkey or Google Chrome, I am part of programming languages users and I can tell you for sure that the decision to remove arguments.callee from the language will be a complete mess. The Main Aim Of ECMAScript 5: Do Not Break What We Have So Far Unfortunately, Internet Explorer will be broken , because named function persists in the scope , causing naming conflicts everywhere ! setTimeout(function f(){ alert(window.f); }, 1000); Above code will alert the function f in every Internet Explorer . Moreover, as you can read in one comme of John's entry, Internet Explorer has function interpretation "problems" , d...