My JavaScript book is out! Don't miss the opportunity to upgrade your beginner or average dev skills.

Thursday, September 09, 2010

JavaScript Protected Properties

Imagine this simple piece of code:

var obj = {
_name: "protected",
gimmeName: function () {
return this._name;
}
};

obj.gimmeName(); // "protected"
obj._name; // throws new Errror

now, imagine I have the simplest solution ever, compatible with both ES5 and ES3 genric implementations ... now please keep reading to know a bit of background :)


The JS Meaning Of Protected

JS developers know that in JavaScript properties are always public and that it is possible to attach/detach properties in any moment to a generic object. Regardless this fact, many libraries consider protected, by naming convention, all those properties whose name start with "_".


You Are Doing It Wrong

First of all I keep saying that is a common error trying to bring classical Object Oriented concepts into a completely different language as JavaScript is, but it does not matter ... we want protected stuff, right?
Due dynamic nature, the common protected meaning is pointless. See this example:

var obj = {
_name: "",
getName: function () {
return this._name;
},
setName: function (_name) {
this._name = _name;
}
};

getName and setName method are theoretically the only one able to change the _name property ... correct? Why, 'cause these are object methods ???

var obj.iCreateAnotherMethod = function (_whateverIWant) {
this._name = _whateverIWant;
};
obj.iCreateAnotherMethod(
"JS protected JOKE"
);

Now try to argue that a dynamic object with a dynamic associated method should not be able to perform the same operation setName does ...


At Least Do It Better!

All protected I have seen so far are quite prolix, inefficient, or pointless.
First of all, let's analyze the problem: what protected should be.
For protected we may consider all those properties or methods that should not be accessed directly but that can be accesses by public (or protected) methods of the same instance.
In few words, we would like to be sure that these properties are not easily accessible outside the object.


An ES5 Friendly Implementation



Object.defineProtectedProperty = (function (
defineProperty // from Object
) {
// (C) WebReflection - Mit Style License

// check that a caller is an object method
function check(object, caller) {
// this function accesses enumerable
// properties.
// returns instantly if check()
// was the property accessor
// (avoid recursion)
if (caller === check) {
return;
}
// avoid direct calls
// in the global scope
// ( or via apply/call )
if (caller) {
for (var key in object) {
if (
// the caller is a method
// ( property wrapper )
object[key] === caller
) {
return;
}
}
}
// if the method was not attached/inherited
// fuck up the execution with an error
throw "access denied";
}

// named expression (we like debugging)
return function defineProtectedProperty(
object, // the generic object
key, // the generic key
description // the ES5 style description
) {
// cache the value
var value = description.value;
// remove it since get/set + value
// does not make sense
delete description.value;
// define the getter
description.get = function get() {
check(object, get.caller);
return value;
};
// define the setter
description.set = function set($value) {
check(object, set.caller);
value = $value;
};
// define and return
return defineProperty(object, key, description);
};
}(Object.defineProperty));

Here some usage example:

// generic object
var o = {
greetings: function () {
this._sayHello();
}
};

// protected property
Object.defineProtectedProperty(
o, "_hello",
{value: "Hello World"}
);

// protected method
Object.defineProtectedProperty(
o, "_sayHello",
{enumerable: true, value: function () {
alert(this._hello);
}}
);

// method call
try {
o._sayHello();
} catch(e) {
alert(e); // access denied
}

// property access
try {
o._hello = "no way";
} catch(e) {
alert(e); // access denied
}

o.greetings(); // Hello World

The only thing to remember is that by default, enumerable is false so, if we would like to access a protected property inside a protected method, we must set it as enumerable so the for/in loop can discover it and verify it as object method.
Pros: compatible with all latest browsers, included IE9, with the only exception of WebKit and Safari (but I have already filed a bug there). It is possible to specify all defineProperty description, in this case except get and set.

Cons: not compatible with less recent browsers plus the check may cost if protected properties are constantly accessed. Address these properties once if it's needed to use them multiple time. Set them once as well if it's needed to change their value.


An ES3 Friendly Implementation

Here the version compatible with many other browsers, witohut the possibility to set ES5 properties such enumerable, configurable, and writable. It is also not possible to avoid a delete operation, which could cause problems.

Object.defineProtectedProperty = (function () {

// (C) WebReflection - Mit Style License

// check that a caller is an object method
function check(object, caller) {
// this function accesses enumerable
// properties.
// returns instantly if check()
// was the property accessor
// (avoid recursion)
if (caller === check) {
return;
}
// avoid direct calls
// in the global scope
if (caller) {
for (var key in object) {
if (
// the caller is a method
// ( property wrapper )
object[key] === caller
) {
return;
}
}
}
// if the method was not attached/inherited
// fuck up the execution with an error
throw "access denied";
}
return function defineProtectedProperty(
object, // the generic object
key, // the generic key
value // the generic description
// only value is considered
) {
value = value.value;
// define the getter
object.__defineGetter__(key, function get() {
check(object, get.caller);
return value;
});
// define the setter
object.__defineSetter__(key, function set($value) {
check(object, set.caller);
value = $value;
});
// return the object
return object;
};
}());

The same usage showed in the precedent example so that migration to ES5 version will be less painful.

Pros: compatible with almost all current browsers except IE family and WebKit/Safari due same bug reported before.

Cons: less secure than ES5 version since delete operation is allowed and properties then re-configurable. Other cons from ES5 version.


The caller Is Dead, Long Life to the Caller

In ES5 they keep removing powerful stuff considering all developers idiots unable to understand JS ... at least this is my feeling when I read things like "the with statement is dangerous" and "with 'use strict' caller should throw an error".
I don't really mind if they remove arguments.callee, we can always use function expressions (IE < 9 a part), but the genericFunction.caller is one of the most fundamental properties every function could possible have.
As instance, it wouldn't be even possible to think about my protected proposal without the caller, while internally all engines know who is the first level outer scope since they need it for variables resolution (e.g. when an inner scope uses an outer scope variable). Is this truly a performances issue? I don't think so, but I have not yet tested it so ... let's see ...


A Scoped Alternative For Every Browser

The only real private thing in JavaScript is a function scope, where this is private only from its outer scope, unless we don't hack it bringing there stuff via eval:

function toOuterScope($) {

var x = 1;

return eval($);
}

alert(toOuterScope("++x")); // 2
alert(typeof x); // undefined

Accordingly, the best way ever to ensure some sort of protection is to store properties into a private scope.
This is the alternative that works with every browser:

var scoped = (function () {

// (C) WebReflection - Mit Style License

// the only real private thing in JS
// is a function scope, like this one
// variables here are private/scoped as well
var
stack = [], // objects collection
id = [], // objects ids
n = -1, // object not found
// minifier shortcuts
indexOf = "indexOf",
push = "push",
splice = "splice"
;

// speed up the get(self, key)
// if indexOf returns -1 we don't care
// we return something from Object.prototype
stack[n] = {};

// ensure that outside nobody can change
// id or stack used Array.prototype methods
// (assignment rather than inherited chain)
id[push] = id[push];
id[splice] = (stack[splice] = id[splice]);
// for Jurassic browser implement a quick indexOf
id[indexOf] = id[indexOf] || function (value) {
for (var i = id.length; i--;) {
if (id[i] === value) {
break;
}
}
return i;
};

// unregister the object
// and all scoped properties
function clear(self) {
var i = id[indexOf](self);
if (n < i) {
id[splice](i, 1);
stack[splice](i, 1);
}
}

// retrieve the scoped property value
function get(self, key) {
// no shortcut to avoid lookup
// slightly better performances
return stack[id.indexOf(self)][key];
}

// set the scoped property value
function set(self, key, value) {
var i = id[indexOf](self);
if (n == i) {
stack[i = id[push](self) - 1] = {};
}
stack[i][key] = value;
}

// named function (we like debugging, don't we?)
function scoped(key, value) {
var
// verify who called the scoped function
caller = scoped.caller,
// improve minifier ratio
self = this,
// one var is enough, undefined is safer
property, undefined
;
// avoid direct calls
// e.g. obj.scoped()
// in a global context
if (caller) {
// loop them all
for (property in self) {
// check if object's method is the caller
if (self[property] === caller) {
// undefined or null key means clear(self)
return key == null ? clear(self) :
// value === undefined means get(self, key)
// otherwise means set(self, key, value)
value === undefined ?
get(self, key) :
set(self, key, value)
;
}
}
}
// if the method was not attached/inherited
// fuck up the execution with an error
throw "access denied";
}

// ready to go
return scoped;

}());

Above variable can be used as object property (method) or as prototype method without problems, and here we have some usage example:

// generic constructor
function F() {}

// scoped as prototype
F.prototype._scoped = scoped;
// getter
F.prototype.getProtected = function (key) {
return this._scoped(key);
};
// setter
F.prototype.setProtected = function (key, value) {
this._scoped(key, value);
};
// clear all scoped properties
F.prototype.clearProtected = function () {
this._scoped();
};

// generic instance
var f = new F;

// set protected
f.setProtected("test", 123);
alert(f.getProtected("test")); // 123

// re-set
f.setProtected("test", 456);
alert(f.getProtected("test")); // 456

// clear all
f.clearProtected();

alert(f.getProtected("test")); // undefined

// try to access scoped
try {
f._scoped();
//scoped.call(f, "whatever");
} catch(e) {
alert(e); // access denied
}

Less Magic With Methods

If we would like to reproduce initial code example, we should tweak the object in a weird way, e.g.


var o = {
_scoped: scoped,
init: function () {
var self = this;
self._scoped("_hello", "Hello World");
self._scoped("_sayHello", function _sayHello() {
self._sayHello = _sayHello;
alert(self._scoped("_hello"));
delete self._sayHello;
});
},
greetings: function () {
this._scoped("_sayHello")();
}
};

// call the init to set scoped properties
o.init();

try {
o._scoped("_sayHello")();
} catch(e) {
alert(e); // access denied
}

try {
o._scoped("_hello", "no way");
} catch(e) {
alert(e); // access denied
}

o.greetings(); // Hello World

This latest alternative is indeed ideal for properties but not methods.
Pros: compatible with basically every browser. No enumeration at all, detached properties.
Cons: not intuitive as other options. Properties must be set via init. We need to clear properties when we don't need the object anymore. Performances are not better than other options.


As Summary

Protected properties are closer here but still we should remember the runtime method that should logically be able to set a protected property ... this is JavaScript, not Java or C#, so probably we should be stuck with the idea that protected and private, in latter case scope talking a part, do not make sense and whatever we do can only decrease overall performances, too often granting a slightly better security.

Friday, August 20, 2010

Object.defineProperty ... but Strict!

In my precedent post entitled A Pascal record via JavaScript I have showed a basic function able to emulate type hints behavior via JavaScript.
Even if that was a proof of concept, I consider other languages simulation of unsupported features an error, first of all because the behavior will rarely be exactly the expected one, secondly because our curent programming language may already have something similar to better learn and use.

A new ES5( direction )

As soon as I have written the Pascal example, I have realized that the good "old" Object.defineProperty, implemented in all major browsers (IE < 9 sucks, you know that ...), has basically the same meaning: define object accessors.

The only missing part, intrinsic in the JavaScript nature, is the property type, where this type could be eventually used for arguments or returns checks when the property is a method.

My Early Attempts

Back in May 2007, my JavaStrict experiment was already trying to do something similar, something implemented after 2 years even in dojo framework as well.
This may tell us that "somebody" would really like to put this kind of checks on daily code, even if performances cannot obviously be the best possible one.

Production VS Deployment

Keeping always in mind that performances matter, the new little monster I am going to show here can be flagged with a boolean, nothing different from:

Object.defineStrictProperty.production = true;

Once in place, the whole logic will switch from "strict type" to "free type" and the used function will be the native Object.defineProperty respecting basically the same behavior.

Object.defineStrictProperty / ies

I have put the code in devpro.it, while I am going to show how it works here.

How to declare a type

Next piece of code is the most basic usage of this method.

var myObject = Object.defineStrictProperty({}, "name", {
type: "string"
});

myObject.name = "it's a me!";

alert(myObject.name);

myObject.name = 123;

// throw new TypeError("wrong type");
//
// console.log =>
// Object
// > expected: "string"
// > received: 123



The meaning of "type"

The type property can contain any of these values:
  • string, where the check will be performed against the typeof value (e.g. "string", "number", "boolean", etc)

  • function, where the check will be performed against the value instanceof type (e.g. Function, Object, Array, Date, etc)

  • object, where the check will be performed against the type.isPrototypeOf(value) (e.g. Array.prototype, others ...)

The only exceptions are null and undefined.

How to declare a returned value

If the property type is "function" or Function there are other extra properties we could define such returns and arguments. Here there is a returns example:

var myObject = Object.defineStrictProperties({}, {
name: {
type: "string",
value: "it's a me!"
},
toString: {
type: "function",
returns: "string",
value: function () {
return this.name;
}
}
});

alert(myObject); // it's a me!

myObject.toString = function () {
return 456;
};

alert(myObject);

// throw new TypeError("wrong return");
//
// console.log =>
// Object
// > expected: ["string"]
// > received: 456


Multiple returns

Since JavaScript is dynamic, there is nothing wrong, logic a part, into different returns. To make it possible we simply need to specify an array with all expected types.

// precedent code with this difference
...
toString: {
type: "function",
returns: ["string", "number"],
value: function () {
return this.name;
}
}

// precedent example won't fail now


How to declare expected arguments

Similar returns concept applied to arguments, so that we can specify a single argument type, a list of arguments type, a list of arguments. Here the difference:

...
setName: {
type: "function",
// checks if a single argument
// with typeof string has been sent
arguments: "string",
// same as above
arguments: ["string"],
// checks if two arguments
// with typeof string and number
// has been sent, order matters!
arguments: ["string", "number"],
// checks if one argument
// with typeof string OR number
// has been sent
arguments: [["string"], ["number"]],
value: function (name) {
this.name = name;
}
}
...

The number of arguments and relative overload per call is arbitrary. As example, we could have a method defined with these arguments without problems.

// generic object for Ajax calls
...
get: {
type: "function",
returns: "string",
arguments: [["string"], ["string", "string", "string"]],
value: function (uri, user, pass) {
this.open("get", uri, false, pass && user, pass);
this.send(null);
return this.responseText;
}
}
...

With a simple logic like that we can "enforce" the program to send one argument or three when, if three, all of them will be checked as strings.

Unlimited arguments

We may decide that the first argument is the only one we would like to check. Well, in this case we can simply create a group of allowed types and ignore the rest.
The arguments logic should be flexible enough due JavaScript nature where overloads can only be simulated via number or tye of arguments checks.

Getters and Setters

The whole logic behind is based on get/set property descriptor, where a nice fallback to __defineGetter__ or __defineSetter__ will be used when Object.defineProperty is missing.
This means that we can describe properties the same way we could do via Object.defineProperty, using enumerable and others as well to make the whole code gracefully degradable when the production flag is set to true.

As Summary

Unless developers won't be interested into this approach, I think this method is basically complete as is and we can use it at own risk.
The whole script stays in about 870 bytes minified and gzipped, not a big deal for what it offers.
In any case, I am looking forward for your feedback!

Wednesday, August 18, 2010

A Pascal record via JavaScript

... all right, I am off for holidays and I won't have probably time to write the post I have twitted a few days ago since it could take a whole day ... however, I am "cleaning" my good old room here in Italy and I have found an Italian book titled "ALGORITMI IN PASCAL" (Pascal Algorithms) a back in 1987 IT book for secondary school.

I could not resist to read it entirely, just to see what kind of Algo I could have found there ... but "surprise", it was not about algos, more about (T)Pascal itself.

Since at the of the day Pascal is somehow the basis for all we can write today, I thought it would have been a nice experiment to try to reproduce the record concept via JavaScript.

What Is a Record

Nothing different from a predefined structure of types, similar to a classic literal object in JS except the structure defines type hints.

// simple Pascal function example
function personToString(self:person);
begin
writeln(self.name, ' is ', self.age, ' years old')
end;

// basic record example
type person = record
name:string[20];
age:integer
end;

// record usage
var me:person;

begin
me.name := "Andrea";
me.age := 32;
personToString(me)
end.

Please note I don't even know if above program will ever run so take it just as an example.

Record VS Prototype

As we can see the record is not that different from a "class" description via prototype, except rather than values we can specify the type of these values.
This approach may be handy even in JavaScript since there is no type hint but sometimes we may desire to make some behavior consistent and hopefully safer.

A first JavaScript record example

Using some ES5 feature, we could be able to write something like this:

function record(description) {
// (C) WebReflection - Mit Style License
var
shadow = {},
self = {}
;
Object.keys(description).forEach(function (key) {
var
type = description[key],
check
;
if (!type) {
throw new TypeError("unable to check a type for property: " + key);
}
switch (typeof type) {
case "string":
check = function (value) {
return typeof value == type;
};
break;
case "function":
type = type.prototype;
default:
check = function (value) {
return type.isPrototypeOf(value);
};
break;
}
this(self, key, {
get: function () {
return shadow[key];
},
set: function (value) {
if (!check(value)) {
throw new TypeError("type violation for property: " + key);
}
shadow[key] = value;
},
configurable: false
});
}, Object.defineProperty);
return self;
}

Here a basic usage example for above function:

var person = record({
name: "string",
age: "number",
toString: Function
});

person.name = "Andrea";
person.age = 32;
person.toString = function () {
return this.name + " is " + this.age + " years old";
};

alert(person);
// Andrea is 32 years old

Following the same concept we may decide to add arbitrary types and relatives checks such "integer", "real", or whatever we need.
Here there is a version compatible with almost all browsers but IE:

function record(description) {
// (C) WebReflection - Mit Style License
function getter(key) {
return function () {
return shadow[key];
};
}
function setter(key) {
var
type = description[key],
check
;
if (!type) {
throw new TypeError("unable to check a type for property: " + key);
}
switch (typeof type) {
case "string":
check = function (value) {
return typeof value == type;
};
break;
case "function":
type = type.prototype;
default:
check = function (value) {
return type.isPrototypeOf(value);
};
break;
}
return function (value) {
if (!check(value)) {
throw new TypeError("type violation for property: " + key);
}
shadow[key] = value;
};
}
var
shadow = {},
self = {}
;
for (var key in description) {
if (description.hasOwnProperty(key)) {
self.__defineGetter__(key, getter(key));
self.__defineSetter__(key, setter(key));
}
}
return self;
}


Record And Prototype Problem

Unfortunately we cannot use this strategy to create constructors prototypes since the shared object (singleton) will use a single shadow for every instance.

function Person(name, age) {
this.name = name;
this.age = age;
}

Person.prototype = record({
name: "string",
age: "number",
toString: Function
});

Person.prototype.toString = function () {
return this.name + " is " + this.age + " years old";
};

var me = new Person("Andrea", 32);
var other = new Person("unknown", 29);

alert(me); // unknown is 29 years old

To avoid this problem we should use return this["@" + key]; in the getter and this["@" + key] = value; in the setter, setting if possible the property as enumerable:false if we have an ES5 friendly environment.
This should make the trick but still there is something not that friendly for JS developers.

A Proper JSRecord


A more flexible approach would let us define at the same time both type and default value, so that prototype definition and type hint could be done in one single call.
How could we write something similar? Here my last revision (done while I was writing this post):

function JSRecord(description) {
// (C) WebReflection - Mit Style License
var
self = {},
cDONTwe = {configurable: true, writable: false, enumerable: false},
hasOwnProperty = self.hasOwnProperty,
defineProperty = Object.defineProperty
;
Object.keys(description).forEach(function (key) {
var
current = description[key],
type = hasOwnProperty.call(current, "type") ? current.type : current,
enumerable = hasOwnProperty.call(current, "enumerable") ? current.enumerable : true,
$key = "@" + key,
check
;
if (!type) {
throw new TypeError("unable to check a type for property: " + key);
}
switch (typeof type) {
case "string":
check = function (value) {
return typeof value == type;
};
break;
case "function":
type = type.prototype;
default:
check = function (value) {
return type.isPrototypeOf(value);
};
break;
}
defineProperty(self, key, {
get: function () {
return this[$key];
},
set: function (value) {
if (!check(value)) {
throw new TypeError("type violation for property: " + key);
}
cDONTwe.value = value;
defineProperty(this, $key, cDONTwe);
},
configurable: false,
enumerable: enumerable
});
if (hasOwnProperty.call(current, "value")) {
self[key] = current.value;
}
});
return self;
}

How things changed:

// we can have defaults
function Person(name, age) {
this.name = name;
if (age) this.age = age;
}

// we can define a type hint
// or we can define both hint
// and value plus enumerable

Person.prototype = JSRecord({
name: "string",
age: {
type: "number",
value: 0
},
toString: {
enumerable: false,
type: Function,
value: function () {
return this.name + " is " + this.age + " years old";
}
}
});

// we can test everything now
var me = new Person("Andrea", 32);
var other = new Person("unknown");

alert(me); // Andrea is 32 years old
alert(other); // unknown is 0 years old

alert(me instanceof Person); // true

for (var key in me) alert(key);
// name, age

What do you think? Here my partial list of pros and cons:

Pros

  • easy type hint implementation
  • safer objects, properties and methods
  • usable as record or prototype without shared vars problems


Cons

  • requires ES5 compatible environment
  • getters and setters are slower than direct access due function overload
  • type hint is slower due checks for each set

Saturday, July 31, 2010

Tesla Experiment, aka JavaScript Lightnings

Hardware Accelerated Browsers are a great step forward for Web potentials, but not all of them are able to accelerate properly the canvas element.

When it comes to performances, we should be aware about those practices able to slow down consistently not that powerful devices such Netbooks and smart pad or phones.

The Tesla Experiment




This demo has a mere entertainment purpose and it is specially suitable for iPad since it becomes more funny via multi touch screens.

It is possible to customize almost everything via the Tesla class, and for the example page we can simply use the query string.

All properties has been explained in the source code of the index page, when the Tesla instance is initialized.

Here another configuration example ( more "Dragon Ball" style :D )


It has been interesting to test how the blur can destroy performances, as interesting was to realize that with current canvas API, a nicer FX as this one could be is quite impossible if performances matters for nowadays mobile devices.

Have fun with the experiment ;-)

Tuesday, July 27, 2010

Constructorification

... he he, I know the title could not be worst, but after my last post about Arrayfication I have thought: "... hey, the Thing.ify(object) could be more than handy in many occasions such mixins and duck typing ...".

So, let me introduce the Function.prototype method that nobody will ever use:

Function.prototype.ify = function (o) {
for (var
self = this,
p = self.prototype,
// find a fucking way to implement this in ES3
// ... uh wait, there's no way to implement
// this in ES3 ...
// https://bugzilla.mozilla.org/show_bug.cgi?id=518663
m = Object.getOwnPropertyNames(p),
i = m.length, n; i--;
) {
// methods only
m[i] = typeof p[n = m[i]] == "function" ?
"o." + n + "=p." + n + ";" : ""
;
}
m.push("return o");
return (self.ify = Function("p",
"return function " +
(self.name || "anonymous") + "fy(o){" +
m.join("") +
"}"
)(p))(o);
};

Since the function requires a Object.getOwnPropertyNames call for its prototype in order to be able to inject it's properties and methods in whatever object, the ify method is lazily assigned.
This code makes "Function.ification" easy so that precedent post could be summarized via:

Array.ify(
document.getElementsByTagName("*")
).forEach(function (node) {
// do stuff with node
});

and be performed at light speed every other time while it won't cost at all until it's performed on whatever constructor the first time only.

Well, at least the technique may result interesting, unfortunately without ES5 it's not possible to reproduce the same behavior without knowing in advance all possible keys part of the native prototype (it's possible for user defined ones tho)

Array.prototype.slice VS Arrayfication

One of the most common operations performed on daily basis directly or indirectly via frameworks and libraries is Array.prototype.slice calls over non Array elements such HTMLCollection, NodeList, and Arguments.

Why We Perform Such Operation


The Function.prototype.apply works only with object created through the [[Class]] Array or Arguments.
In latter case we may like to avoid ES3 arguments and named arguments mess when dealing with indexes.
Finally, in most of the case we would like to perform Array operations over ArrayLike objects to filer, map, splice, change, modify, etc etc ...

The Slice Cost


Let's perform over an ArrayLike object of length 2000, 2000 slice calls (change the length if you have such powerful machine):

// create the ArrayLike object
for(var arguments = {length:2000}, i = 0; i < 2000; ++i)
arguments[i] = i;
;

// define the bench function
function testSlice(arguments) {
var t = new Date;
for (var slice = Array.prototype.slice, i = 0, length = arguments.length; i < length; ++i)
slice.call(arguments);
;
return new Date - t;
}

// test it
alert(testSlice(arguments));

The average time in my Atom N270 based Netbook is 1750 ms, and numbers are not that unreasonable.
While a list of 2000 generic values may be not that common, the number of slice.call may be definitively more than 2000 during an application life cycle. All this wasted time to simply transform a generic list into an Array? And maybe just to loop and re-loop over it to filter or change values and indexes?

Alternative One: __proto__


If we modify the __proto__ property of whatever object and in almost all browsers (not IE, of course), we can somehow "promote" the current object to Array, except for the [[Class]] that will still be the generic Object, or Arguments.
The undesired side effect is that the modified object won't find anymore in its prototype its original methods, so we can define this technique really greedy.
But what about performances?

// function to test
function testProto(arguments) {
var t = new Date;
for (var proto = Array.prototype, i = 0, length = arguments.length; i < length; ++i)
arguments.__proto__ = proto;
;
return new Date - t;
}

// the result using precedent arguments object
alert(testProto(arguments));

The average elapsed time in this case is 40 ms but we have to remember is that we are not converting the object into an Array instance, we are simply overwriting it's inherited properties and methods with those part of the Array.prototype object.
This means that push, unshift, splice, forEach, or other operations, will be accessible directly through the object (e.g. arguments.forEach( ... ))
If these methods are the reason we would like to slice the generic object, this solution is definitively preferred.

Alternative Two: Arrayfication


To avoid the undesired side effect obtained via __proto__ assignment, the removal of inherited methods, we may consider to use call or apply directly via Array.prototype.
The imminent side effect of this technique is that potentially every function may like to use one of the Array prototype methods against the same object which is always passed by reference.
A simple solution could be the one to attach directly a method to this object, so that every part of the application will be able to use, as example, a forEach call for this object, without accessing every time the Array.prototype.forEach method.

arguments.forEach = Array.prototype.forEach;
// now use forEach wherever we need
// with arguments object

Since every function may like to use one or more Array methods, how about creating a function able to attach all of them in one shot?

Array.fy = (function () {
// (C) WebReflection - Mit Style License
for (var
m = [
"pop", "push", "reverse", "shift", "sort", "splice", "unshift",
"concat", "join", "slice", "indexOf", "lastIndexOf",
"filter", "forEach", "every", "map", "some", "reduce", "reduceRight"
],
i = m.length; i--;
) {
m[i] = "o." + m[i] + "=p." + m[i];
}
m.push("return o");
return Function("p",
"return function Arrayfy(o){" + m.join(";") + "}"
)(Array.prototype);
}());

With a single call we can attach all current available Array.prototype methods once without getting rid of current inherited properties or methods.
Let's see how much does a call cost:

// test function for Array.fy
function testArrayfy(arguments) {
var t = new Date;
for (var fy = Array.fy, i = 0, length = arguments.length; i < length; ++i)
fy(arguments);
;
return new Date - t;
}

// bench
alert(testArrayfy(arguments));

The average elapsed time for this operation is 3 ms.
After a single call we can consider the generic object an Array duck, preserving its inheritance.
The greedy aspect is about possible overwrites, but I have personally never called a method forEach if this is not exactly representing the Array.forEach method.

Arrayfied Operations


The last benchmark we can do is about common Array operations over our Arrayfied object.
The first consideration to do is that slice, as every other Array operation, seems to be extremely optimized for real Array objects.
In few words if we need to transform because we need many calls to forEach, filter, map, slice, etc, the transformation via slice is probably what we are looking for.
But if we need a generic loop over a generic callback and just few times, Array.fy proposal is probably the most indicated one. Here some extra test:

// slice plus a forEach operation
function testSliceEach(arguments) {
var t = new Date;
for (var slice = Array.prototype.slice, fn = function() {}, i = 0, length = arguments.length; i < length; ++i)
slice.call(arguments).forEach(fn);
;
return new Date - t;
}

// just forEach through Arrayfied object
function testArrayfied(arguments) {
var t = new Date;
Array.fy(arguments);
for (var fn = function() {}, i = 0, length = arguments.length; i < length; ++i)
arguments.forEach(fn);
;
return new Date - t;
}

// just slice through Arrayfied object
function testArrayfiedSliced(arguments) {
var t = new Date;
Array.fy(arguments);
for (var fn = function() {}, i = 0, length = arguments.length; i < length; ++i)
arguments.slice();
;
return new Date - t;
}

// bench

alert(testSliceEach(arguments)); // 3200ms
alert(testArrayfied(arguments)); // 2400ms
alert(testArrayfiedSliced(arguments));// 1700ms

The last test is against a classic slice.call and it costs basically the same.
First and seconds demonstrate that if we slice to use native power we are actually spending more time than using native power directly.
Bear in mind that if the variable is already an Array, slice will cost much less and the average against the last test will be 1350 ms.

IE And Conclusions


I keep saying that IE should simply have normalized Array.prototype, ignoring those person that wrongly rely in for in loops over arrays when it's not necessary, and making this Array.fy portable for IE world as well since the internal proto variable is a pointer to the original Array.prototype then automatically ready for natives standard enhancements.
The nice part is that rather than see Array.prototype.something.call in every piece of code we can easily use one fast call to have them all ... so, you decide :-)

.. last minute Example ...


Just because sometimes we lack of fantasy, here a generic usage for Array.fy:

function $(selector, parentNode) {
return Array.fy((parentNode || document).querySelectorAll(selector));
}

$("div").forEach(function (div, i, nodeList) {
div.innerHTML = "Array.fy rocks!";
});


Update
just for testing/performances purpose:

Array.ify = (function () {
// (C) WebReflection - Mit Style License
for (var
m = [
"pop", "push", "reverse", "shift", "sort", "splice", "unshift",
"concat", "join", "slice", "indexOf", "lastIndexOf",
"filter", "forEach", "every", "map", "some", "reduce", "reduceRight"
],
f = [],
i = m.length; i--;
) {
f[i] = "var " + m[i] + "=p." + m[i];
m[i] = "o." + m[i] + "=" + m[i];
}
m.push("return o");
return Function("p", f.join(";") +
";return function Arrayfy(o){" + m.join(";") + "}"
)(Array.prototype);
}());

Thursday, July 01, 2010

JavaScript FatalError

just in case at some point you decide to break everything, regardless possible try catches around ...

function FatalError(message, file, line){
function toString() {
throw e;
}
var e = this;
e["@message"] = message;
e["@file"] = file || e.file || e.fileName;
e["@line"] = line || e.line || e.lineNumber;
if ("__defineGetter__" in e) {
e.__defineGetter__("message", toString);
e.__defineGetter__("description", toString);
} else {
e.message = e.description = {toString: toString};
}
// just in case, but not necessary
e.toString = e.valueOf = toString;
};
(FatalError.prototype = new Error).name = "FatalError";

how to use it?

throw new FatalError("this must be a joke!");

P.S. it won't work if Errors are not logged ( silent failures, definitively a problem for certain applications ;) )

Wednesday, June 30, 2010

JavaScript Random Hints

Update some point has been made more clear, thanks to Dmitry Soshnikov for suggestions.


Forget the global undefined


Too many developers relies into undefined variable in ES3, and all they should do is to set undefined = true on global scope and see if the application or all unit tests break or not. I am going to demonstrate how simple is, at least in ES3, to redefine by mistake the global undefined.

// inside whatever closure/scope
function setItem(key, value) {
this[key] = value;
}

// later in the scope, setItem may be reused
// through call or apply for whatever object
setItem.call(myObject, myKey, "whatever value");

// if for some reason the first argument used as context
// is undefined, the "this" will point to the global context

// if for some reason the second argument used as key
// is undefined, the accessor will cast it as undefined string

// the result of latter call with these two
// common or simple conditions
// is the quivalent of:

window.undefined = "whatever value";

// where window["undefined"] or window[undefined]
// are the equivalent of window.undefined

undefined; // "whatever value"

Here a list of side effects every time we deal with undefined:

  • it is not safe to compare variables against undefined since it is simply implicitly declared as unassigned variable, as var u; could be, but in the global scope

  • it is not possible to minify it since it is a well known variable

  • its access is slow, since requires scope lookup potentially up to the global one every time we write that bloody variable name in our code, wherever it is


Here is a list of best practices to avoid the usage of undefined:

  • define your own undefined variable, if necessary, via var undefined;, and only if you are sure that nothing can change it's value in the current scope (e.g. eval)

  • the first point will allow minifiers/compilers to shrink the undefined variable into, possibly, one char, so it is size safe

  • if null value can be considered undefined as well, where both undefined and null do not support accessors such unknown.stuff, compare the potential undefined variable against null, since by specs null == null && null == undefined && null != 0 && null != "" && null != NaN && null != false && null != whateverThatIsNotNullOrUndefined


About latter point, null is a constant so no lookup is performed since we cannot re-assign the null value and every time somebody tells you something like: "doooode, JSLint is complaining about that 'v == null'" simply tell him that JSLint is suggesting a bad practice and point this person to this post :D
About typeof v === "undefined" ? Bullshit! a typeof operation with an eqeqeq against a string that cannot be minified ... are you a programmer that knows the language or you think JSLint, as automation tool, is the bible? In the second case I have already posted JSLint: The Bad Part why this tool is not always ideal: have a look!
It must be told that in ES5 the global undefined won't be enumerable/writable/configurable anymore, and that showed example will fail since this reference, when null or undefined is passed through call/apply, will be null as well (errors).

Cache the bloody variable or namespace !


It does not matter how fast and cool are nowadays CPUs, it's about common sense.
If you spot something like:

my.lib.utils.Do.stuff(some);
my.lib.utils.Do.stuff(thing);

fix it ASAP!
This is a list of side effects caused by duplicated access for whatever it is:

  • a namespace requires a lookup usually up to the global scope, this costs time behind the scene

  • minifiers/compilers cannot optimize anything so far since properties cannot be shrinked so this technique is bigger application size prone

  • getters are always invoked, and 99.9% of the time this is not what we are looking for. JavaScript has a beautiful and easy interface exposed to developers but behind the scene there are 90% of the time getters which means slower performances for everybody.


About latter point, we can simply check, from one of the fastest browsers in the market, how much a simple node.childNodes[0] could cost.
If you are not familiar with C++, just imagine this piece of JavaScript every time we access an index of some Array:

Array.prototype.item = function (index) {
var
undefined,
pos = 0,
// useless if we return lastItem but for some reason there ...
n = this.slice(0, 1)
;
// optimized for multiple access with the same index
if (this._isItemCacheValid) {
if (index == this._lastItemOffset)
return this._lastItem;

var
diff = index - this._lastItemOffset,
dist = Math.abs(diff)
;
if (dist < index) {
n = this._lastItem;
pos = this._lastItemOffset;
}
}
if (this._isLengthCacheValid) {
if (index >= this._cachedLength)
return undefined;

var
diff = index - pos,
dist = Math.abs(diff)
;
if (dist > (this._cachedLength || (this._cachedLength = this.length)) - 1 - index) {
n = this[this._cachedLength - 1];
pos = this._cachedLength - 1;
}
}
if (pos <= index) {
while (n && pos < index) {
n = this[pos];
++pos;
}
} else {
while (n && pos > index) {
n = this[pos];
--pos;
}
}
if (n) {
this._lastItem = n;
this._lastItemOffset = pos;
this._isItemCacheValid = true;
return n;
}
return undefined;
};

Array.prototype._lastItemOffset = 0;

[1,2,3].item(0);

Now, consider above code against what we usually do which is simply arr[0] ... and consider that this is just the single item access for a ChildNodeList collection ... how many other operations we want to perform through DOM searches, namespaces, Array access, etc etc? Cache It Whenever It Is Possible!, and this should be the point number one in every "performances oriented" article or book.

The only thing to consider when we cache are object methods, if we "de-context" a method that use this reference inside, we can simply cache the object, it is going to be enough, but if we access a property twice, as often happens with domNode.style property, as example, cache it!

// my.name.space.Do.stuff is a method
// of my.name.space.Do where this is used

// WRONG
var stuff = my.name.space.Do.stuf;
stuff(); // global this in ES3, error in ES5

// BETTER
var Do = my.name.space.Do;
Do.stuff();


Use the in operator


For the same getter/access reason, this classic check can be harmful:

if (someObject.property) {
// do stuff with property
}

Specially if we are dealing with host objects, some access could cause errors (e.g. (domNode || unknown).constructor in IE or similar operations) while a classic:

if ("property" in object) {
// do stuff with object.property
}

can "save the world" since we do not access the property but we simply check if it is accessible ... a tiny difference extremely important and fast in any case.

Avoid redundant Function Expressions


We are kinda lucky here, since functions as first class objects, are truly fast to create in JavaScript. These do not require a class to be used, neither an object or special tricks, these are simply variables able to be invoked executing what has been defined inside their body through an activation context process, plus named arguments, the length of these arguments, the name of the function, if any, plus arguments variable if accessed in the body, and "almost nothing else" ... but we can already get the fact functions do not come for free, do we?

Here there are a couple of function expression common mistakes.

Closure inside a Loop



// WRONG
// the classic way to avoid
// unexpected behavior on lazy evaluation
// the equivalent of 20 functions
for (var i = 0; i < 10; ++i) {
(function (i) {
setTimeout(function () {
alert(i);
}, 15);
}(i)); // trap it!
}

// BETTER
// 11 functions rather than 20
// same behavior, better performances
for (var
getTimeout = function (i) {
return function () {
alert(i);
};
},
i = 0; i < 10; ++i
) {
setTimeout(getTimeout(i), 15);
}


Array.extras Misunderstood



// WRONG
// a new expression for each Array.extra operation
// a lookup to access another this reference
var self = this;
what.forEach(function (value, index, what) {
// do something
self[index] = value;
});
ever.forEach(function (value, index, what) {
// do something
self[index] = value;
});

// BETTER
// 1 function against N
// this reference through the native interface
// easier to debug/maintain/improve/change
function forThisEachCase(value, index, what) {
this[index] = value;
}
what.forEach(forThisEachCase, this);
ever.forEach(forThisEachCase, this);


Use Natives !!!


Newcomers are lazy, it does not matter if they are noob or they have 10 years of Java, PHP, Python, C#, or Ruby over their shoulders, they will always look for a framework able to do truly simple stuff for the simple reason that they don't know/get yet JavaScript which is different from every other common programming language. This is the best starting point to slow down every little operation.
Many frameworks offer classes, mixins, native wrapper which aim is often the one to invert arguments for whatever reason simplifying operations (e.g. the classic $.eash in jQuery which is making junior developers think that the native forEach will pass the index as first argument and this as current reference).
If three lines based on native prototypes/functionality are more than 1 magic method call, go for it!
Specially if standard, natives will never change while libraries are constantly improving and APIs changing as well for whatever valid reason.
If you need a for in loop, do the for in knowing what you are doing, ignoring JSLint if necessary 'cause you are dealing with objects that inherits from objects and you may be interested into inherited properties/methods as well.
If the problem is the list of property, we can always create safer ways to interact with what we would like to enumerate, as example:

var SafeLoop = (function (id) {
function SafeLoop() {
this[id] = [];
}
SafeLoop.prototype.keys = function() {
return this[id];
};
SafeLoop.prototype.enum = function (key) {
var enumerable = this.keys();
enumerable.push.apply(
enumerable,
typeof key !== "object" ? arguments : key
);
return this;
};
return SafeLoop;
}(Math.random()));

var o = new SafeLoop().enum("a", "b");
o.a = o.b = o.c = o.d = 123;
o.e = 456;

// enum accepts N arguments or an array
o.enum(["c", "d"]);

// fast and safe, without an hasOwnProperty call for each item
for (var key = o.keys(), i = key.length; i--;) {
alert([key[i], o[key[i]]]);
// d, c, b, and a with 123
}

// extend the prototype if necessary
SafeLoop.prototype.forEach = function (callback, context) {
for (var
enumerable = this.keys(),
i = 0, length = enumerable.length,
key;
i < length; ++i
) {
key = enumerable[i];
callback.call(context, this[key], key, this);
}
};

o.forEach(function (value, key, o) {
alert([value, key, o]);
// 123,a|b|c|d,[object Object]
});

Above code is just an example "AS IS" and there are many part to improve. The concept is that JavaScript allows us to define what we need in such simple way and most of the time we don't want to include and "move" a whole framework to do something simple as loops are, as example, do we? If we do, well, we are creating redundant function expressions, including extra bytes for just some extra functionality, and potentially making the application slower ... remember: we are in the mobile era, CPUs are not those you have in your MacBook Pro and frameworks should be used only when we have real benefits, e.g. selector engines or much more complicated methods. Do you agree?

Friday, June 04, 2010

WebSocket Handshake 76 Simplified

update
there was a superfluous CR+LN with char 0x00 that was causing buffer troubles, now fixed



I am working during my free time (... recently extremely hard to have ...) over a little project that I'd like to show at the Front Trends event this October and WebSocket is the key of this project.

While 2 days ago I eventually found a way to communicate in few lines of php with a WebSocket, yesterday Chromium blog announced they "simply changed it", causing basically problems to all those projects based over the good old handshake75.

After I have found in Axod's Hack that somebody else had basically my same thoughts, I still could not find any valid example able to do the new handshake ... so here I am with the first draft-ietf-hybi-thewebsocketprotocol-00 php implementation I know, inspired somehow from the go version.


<?php

class WebSocketHandshake {

/*! Easy way to handshake a WebSocket via draft-ietf-hybi-thewebsocketprotocol-00
* @link http://www.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-00.txt
* @author Andrea Giammarchi
* @blog webreflection.blogspot.com
* @date 4th June 2010
* @example
* // via function call ...
* $handshake = WebSocketHandshake($buffer);
* // ... or via class
* $handshake = (string)new WebSocketHandshake($buffer);
*
* socket_write($socket, $handshake, strlen($handshake));
*/

private $__value__;

public function __construct($buffer) {
$resource = $host = $origin = $key1 = $key2 = $protocol = $code = $handshake = null;
preg_match('#GET (.*?) HTTP#', $buffer, $match) && $resource = $match[1];
preg_match("#Host: (.*?)\r\n#", $buffer, $match) && $host = $match[1];
preg_match("#Sec-WebSocket-Key1: (.*?)\r\n#", $buffer, $match) && $key1 = $match[1];
preg_match("#Sec-WebSocket-Key2: (.*?)\r\n#", $buffer, $match) && $key2 = $match[1];
preg_match("#Sec-WebSocket-Protocol: (.*?)\r\n#", $buffer, $match) && $protocol = $match[1];
preg_match("#Origin: (.*?)\r\n#", $buffer, $match) && $origin = $match[1];
preg_match("#\r\n(.*?)\$#", $buffer, $match) && $code = $match[1];
$this->__value__ =
"HTTP/1.1 101 WebSocket Protocol Handshake\r\n".
"Upgrade: WebSocket\r\n".
"Connection: Upgrade\r\n".
"Sec-WebSocket-Origin: {$origin}\r\n".
"Sec-WebSocket-Location: ws://{$host}{$resource}\r\n".
($protocol ? "Sec-WebSocket-Protocol: {$protocol}\r\n" : "").
"\r\n".
$this->_createHandshakeThingy($key1, $key2, $code)
;
}

public function __toString() {
return $this->__value__;
}

private function _doStuffToObtainAnInt32($key) {
return preg_match_all('#[0-9]#', $key, $number) && preg_match_all('# #', $key, $space) ?
implode('', $number[0]) / count($space[0]) :
''
;
}

private function _createHandshakeThingy($key1, $key2, $code) {
return md5(
pack('N', $this->_doStuffToObtainAnInt32($key1)).
pack('N', $this->_doStuffToObtainAnInt32($key2)).
$code,
true
);
}
}

// handshake headers strings factory
function WebSocketHandshake($buffer) {
return (string)new WebSocketHandshake($buffer);
}

?>


I am pretty sure above code does not need any other comment and methods are "as much semantic as possible", since I completely agree about the Axod point and the fact it's both over engineered and absolutely badly documented via those "specs" ... weird from a company famous for its simplicity concept that maybe this time forgot some KISS approach ...

Sunday, May 02, 2010

Event driven application and the most basic Listener module

Event driven programming is a common technique particularly common in JavaScript applications.

When


The most classic application is the one with DOM and assigned listeners.
We have basically no idea about "what happens when" and we delegate asynchronous logic to our listeners, waiting for user actions.
This kind of approach could be implemented in whatever application creating a chain of events or notifications that must occur when something expected happens.
Other examples of event driven programming are sockets, Ajax calls, and any sort of notification that may occur in order to let the surrounding logic act accordingly.
Often combined with registry pattern, event driven programming can be found inside UI frameworks where components, as example, are notified when sub-components are added or removed. In this way the component always knows its status and it can change accordingly (redraw, repaint, properties, accessors, counters, other notifications).

What

Following the DOM example or, back in 2004, the ActionScript model, events are nothing more than callbacks associated via unique identifier: the event name. The natural order for these callback is FIFO and usually each callback is "fired" with the same object/event as single argument. One de-facto standard about events is that usually there is no need to add twice the same so that one event will be fired just once.
Since the order matter, there is no way to prevent events already assigned to do not fire. The same is for DOM events, preventDefault or stopPropagation won't stop other events associated with the same node to do not fire but, if used, the chain or the behavior after these events are fired may be different.

How

This is one of the most basic Listener implementation: it's a module, suitable for mixins, is a Singleton, usable and shareable across the whole application, and finally it's a little piece of code, basically unbreakable and reliable for what it does.
This is a basic usage example for the Listener module:

function MyListener() {
// create the "protected" listener hash
this.initListener();
}
MyListener.prototype = Listener;

var ml = new MyListener();

var test = function (arg) {
alert(ml === this && arg === 2); // true
};

ml.addListener("test", test);
// won't add the same event
ml.addListener("test", test);

// fire the event
ml.fireListener("test", 2);

// remove the listener
ml.removeListener("test", test);

// check precedent operation
alert(ml.hasListener("test", test)); // false

// fire a listener in any case
ml.fireListener("test", 2); // nothing happens


Why

With this basic functionality we can already start to create an event driven application firing events whenever it is necessary.
As example, an object with a remove/destroy method may involve soe notification. All we need to do in this case is to use something such:

this.fireEvent("destroy", this);

before or after destroy operations. In this way whatever other part of the application that added a listener may act accordingly and the chain of notifications can establish a new environment, if necessary.
The behavior is the same we can found in native DOM events listeners. If a listener is removed runtime it won't be fired and same is if a listener will be added runtime, it will be executed only next time unless we are not firing it again (which means all others will be fired again).

This post would like to be just a starting point for this kind of approach, sometimes we may need to deal with objects that don't know what could happen if one of them has been removed, added, created, or changed so in this way we have a basic component to deal with. Have fun ;-)

Wednesday, April 28, 2010

Object.defineProperty - A Missed Opportunity

Just a quick post about some clever hack we should probably forget ... make old scripts less obtrusive using new ES5 features.
I am talking bout those guys out there that use scripts with a classic:

onload = function () { ... };
// or
this.onload = ...
// or
window.onload ...
// or
self.onload ...
// etc etc


Apparently WebKit Nightly fires an error when we try to define getters and setters via Object.defineProperty and this is already enough to remove that "hoooraayyyy" for my silly test .... here the code:

Object.defineProperty(this, "onload", (function (self, callback) {
function onload(e) {
while (callback.length) {
callback.shift().call(self, e);
}
}
self.addEventListener ?
self.addEventListener("load", onload, false) :
self.attachEvent("onload", onload)
;
return {
get: function () {
return onload;
},
set: function (onload) {
callback.push(onload);
}
};
}(this, [])));


If we put above snippet before any other script, we can be almost sure that nobody will be able to break anything with classic obtrusive operations:

// test above concept via Chrome and maybe IE8 or others
onload = function () {
alert(1);
};

this.onload = function () {
alert(2);
};


That's it, something that may have been good will probably be just a proof of concept :-)

Sunday, April 25, 2010

JSON __sleep, __wakeup, serialize and unserialize

The JSON protocol is a de facto standard used in many different environments to transport objects, included arrays and Dates plus primitives such: strings, numbers, and booleans ... so far, so good!
Since this protocol is widely adopted but it has not the power that a well known function as is the PHP serialize one has, we are often forced to remember how data has been stored, what does this data represent, and eventually convert data back if we are dealing with instances rather than native hashes.
If we consider the ExtJS library architecture, we can basically have a snapshot of whatever component simply storing its configuration object. The type will eventually tell us how to retrieve a copy of the original component back and without effort at all.
Since JSON is the preferred protocol to store data in WebStorages, databases, files, etc etc, and since we can save basically only hashes, loosing every other property, I have decided to try this experiment able to bring some magic in the protocol itself.

JSONSerialize

The absolutely alpha version of this experiment has been stored here, in my little repository. If more than one developer, e.g. me, is interested, I may consider to put it in google code or github with a better documentation while what I can do right now, is to show you what JSONSerialize can do for us, step after step.

Normal JSON.stringify Behavior

This is what happens if we use JSON.stringify, or JSON.serialize, when an object is simply .... well, an object.

// let's test in console or web
if (typeof alert === "undefined") alert = print;

// our "class"
function A() {}

// our instance
var a = new A;

// a couple of dynamic properties
a.a = 123;
a.b = 456;

// our JSON call
var json = JSON.serialize(a);
alert(json); // {"a":123,"b":456}

Nothing new, serialize acts exactly as JSON.stringify, with or without extra arguments ... but things become a bit more interesting now ...

The _sleep Method

In the PHP world we all know there are several methods able to bring some magic in our classes and __sleep is one of these methods. Since the double underscore is usually considered a bad practice, due to private core magic functionalities (e.g. __noSuchMethod__, __defineGetter/Setter__, others) I have decided to call it simply _sleep, considering it a sort of magic protected method, whatever it means in JavaScript :-)

A.prototype._sleep = function () {
return ["a"];
};

json = JSON.serialize(a);
alert(json); // {"a":123}

The aim of _sleep is to return an array with zero, one, or more public properties we would like to export. As we can see, JSON.serialize will take care of this operation returning only what is present in the list.
In few words, no needs to send properties we don't need, cool?
Another advantage of a sleep method is to notify, close, disconnect, or do whatever other operation we need to mark the instance as serialized. In other words sleep could be useful every time we need to deal with a variable that may be updated elsewhere using JSON as transport protocol (postMessage, others).

The serializer Property

_sleep is already a good start point but, if we don't know anything else about that hash, how can we understand which kind of instance was the a variable?

alert(JSON.unserialize(json).constructor);
// Object

Too bad, we have been able to define what we would like to export, but no way to understand what we actually exported.
This is where the serializer property becomes handy, letting JSON.serialze behaves differently.

// define the serializer
A.prototype.serializer = "A";

// re-assign the string and check it out
json = JSON.serialize(a);

alert(json); // {"a":123,"_wakeup":"A"}

// what's new? just this:

alert(JSON.unserialize(json).constructor);
// the function A() {} ... oooh yeah!!!

In few words, with or without a _sleep method, we can bring back to their initial status serialized objects ... but why that _wakeup property? Thank's for asking!

The _wakeup Method

As is for PHP, there is a __wakeup method too which is invoked as soon as the string is unserialized! Being this method somehow protected, I thought it was the best one to put into the JSONSerialize logic.

// let's define a _wakeup method
A.prototype._wakeup = function () {
alert(this instanceof A);
// will be true !!!
};

// let's try again
a = JSON.unserialize(json);

// ... oooh yeah!

As the PHP page shows in some example, the _wakeup function can become really useful when we are saving a database connection or a WebStorage wrapper or whatever cannot be persistent and requires to be initialized so .... at least we can save some info rather than ask them every time, isn't it?
The moment _wakeup will be invoked the instance will already have every exported property assigned, exactly as is for PHP ... wanna something more?

serialize And unserialize Methods

The PHP Serializable interface brings some other magic via the SPL: we decide what we want to export and we receive it back when unserialize is invoked. Same is for JSONSerialize, with higher priority over _sleep and _wakeup but not better performances (right now, I may consider to avoid some extra operation to follow current PHP status tho ...)

// introduce the serialize method
A.prototype.serialize = function () {
return JSON.stringify({c:789});
};

// try this at home
json = JSON.serialize(a);
alert(json); // {"c":789,"_wakeup":"A"}

// this will call the _wakeup since
// unserialize has not been defined yet
// please note the a property won't be there anymore
// cause serialize returned a c instead
a = JSON.unserialize(json);

// let's have priority via unserialize
A.prototype.unserialize = function (data) {
this.b = JSON.parse(data).c;
};

// let's try again, _wakeup won't be invoked
a = JSON.unserialize(json);

// a won't be there, but b will
alert([a.a, a.b]); // undefined,789

And that's all folks!

JSONSerialize Pros

The serializer property accepts namespaces and does not use evaluation. The whole little script does not use evaluation at all and I think this is good, specially for security reason.
Nested objects and arrays are supported as well which means that we can serialize complex hierarchies and have them back without effort and already initialized.

JSONSerialize Cons

Nested means loops, as is for the JavaScript JSON implementation performances are surely slower than a native implementation. At the same time we should consider when we need it, cause our own implementation to bring instances back could cost more. Finally, if we all like this, we may push some browser vendor for a core implementation, no?
Another performance problem is with serialize and unserialize since these requires double parsing in order to respect the behavior.

As Summary

It's not the first time I am trying to enhance the JSON protocol to fit my requirements and this is probably the less obtrusive and secure way I could came out with. I hope somebody will appreciate at least the idea and I am up for all your thoughts ;-)

Sunday, March 28, 2010

new Constructor VS Object.create

just a quick post about ES5 Object.create performances. While in More ES5 Friendly Patterns paragraph I have described how to use new ES5 features to create instances in a better way, I have never tested directly performances against classic ES3 pattern.

The Benchmark Logic

Pretty simple, create a new object with a "privileged property" plus an inherited one. The test prototype looks like this object:

var proto = {toString:function () {
return this.name;
}}

The assumption is that somehow the object should be able to return it's name, which is not shared via prototype.

ES3 Game

I hope I don't have to explain this piece of code:

function F(name) {
this.name = name;
}
F.prototype = proto;

To test above classical pattern, all we need is to confirm this behavior:

var o = new F("instance");
alert(String(o) === "instance");


ES5 Game

Using an updated browser, it should be possible to replicate ES3 behavior via this piece of code:

var o = Object.create(proto, {
name: {
value:"object"
}
});

Right, Object.create comes with much more power than a simple property assignment, but here we are testing a basic task just to analyze what's the outcome, right? Just to be sure about the result:

alert(String(o) === "object");


Optimized ES5 Game

What can we do to improve performances? Avoid global scope look up, the Object constructor, plus use a static/fixed property to cheat the test:

var fixed = {
name: {
value: "static"
}
};

var create = Object.create;

var o = create(proto, fixed);

// the assertion
alert(String(o) === "static");


The Benchmark

Let's put these patterns together inside a closure, execute them 100000 times, retrieving elapsed time.

setTimeout(function () {

var proto = {toString:function () {
return this.name;
}};

var fixed = {
name: {
value: "static"
}
};

function F(name) {
this.name = name;
}
F.prototype = proto;

var o;

for(var i = 100000, instance = new Date; i--;) {
o = new F("instance");
}
instance -= new Date;

for(var i = 100000, object = new Date; i--;) {
o = Object.create(proto, {
name: {
value:"object"
}
});
}
object -= new Date;

for(var create = Object.create,
i = 100000, static = new Date; i--;
) {
o = create(proto, fixed);
}
static -= new Date;

alert([instance, object, static].join("\n").replace(/-/g,"ms: "));

}, 1000);


The Result

Based on Atom N270 nad testing via Chrome 5 for devs, this is what I read in the alert:

ms: 7
ms: 2325
ms: 2218

The first result goes up to 54ms, reaching 5ms, the second one is pretty much stable while the latest one goes down 'till 1987 ms ...

Conclusion

new Constructor seems to be the best option for those cases where the initialize/init/construct method needs to somehow setup the created instance. Only if we need special Object.create features it is worth it to use it, but if we base a whole framework over Object.create, considering eventually emulations for old browsers, this framework will be inevitably slower than older code. This means that as example a classic Point class option, should still be exactly like this:

function Point(x, y, z) {
this.x = x;
this.y = y;
this.z = z;
}

or eventually like the next one, if we don't need chained methods, neither new before each call:

function Point(x, y, z) {
return {x:x, y:y, z:z};
}

by my good old AStar algorithm time, the fastest option ever!

Tuesday, March 16, 2010

Anonymous Style

When a function is to be invoked immediately, the entire invocation expression should be wrapped in parens so that it is clear that the value being produced is the result of the function and not the function itself.

I have already commented the popular JavaScript Code Convention article, but latest cited sentence is probably the only one I have never been sure about.

Why Bother

Actually, I have always found the expression:

var something = function(){

// do stuff
// return something

}(); // invoke
kinda enough to invoke inline a function expression.
Somebody argued that above style is ambiguous.
Since an inline invoke could be performed against a massive function body, the point is that we may need to scroll 'till the end of the function expression to know if it has been executed or not.
In my opinion, whenever there is a function expression, we should always check the end of this function or we'll never be sure about the assigned value.
Fair enough, even if the function could not be necessary invoked:

var something = function(){

// do stuff
// return or not

}.bind(this);
expressions are usually wrapped in any case regardless what's up at the end.

Still ... Why Bother

The most common implementation of this code convention we can find almost everywhere, included my shared code, is this one:

var something = (function(){

// do stuff
// return something

})(); // invoke

What is actually wrong with this implementation?
Let's simply imagine the function returns a function:

var something = (function(){
return function(){
return 123;
};
})();

Now, let's imagine that we would like to execute runtime the returned function, since we know that expression will return one:

var something = (function(){
return function(){
return 123;
};
})()(); // <= WTF?

I am pretty sure that ()() at the end of a runtime invoked expression, will bring us back to origins, where "we had to check 'till the end of the function", at least to understand what is going on ...
In few words, and as I have said, the scroll 'till the end of whatever function should be mandatory, if the code is not our one, and we would like to understand what this code actually does.

Non Ambiguously Speaking

If we follow Mr D. suggestion, we could say that this strategy will be rarely ambiguous.
To spot a wrap is definitively more easy than spot a potential typo, as 4 brackets could suggest:

var something = (function(){
return function(){
return 123;
};
}());
With latter snippet we can certainly say with a quick look that something refers the value returned by the invoked expression. It's wrapped, it must be an invoke rather than a function assignment, and it could be whatever value.
The instant we add other brackets, we are obviously dealing with the returned value:

var something = (function(){
return function(){
return 123;
};
}())(); // invoke the returned value

In other words we are able to split the inline invoked expression, with the rest of the logic, but still scrolling through the end!


Moreover

The usage of brackets makes the assignment superfluous:

// first case analyzed without brackets
(function(){

// do stuff

}());
In this case we are clearly creating a closure to avoid global space pollution and to perform some useful operation.
Since this is basically what we can find almost everywhere in many different libraries or piece of libraries, and since we have some shortcut to instantly reach the end of a file, why should we put the inline invoke outside the operation?

// first case analyzed without brackets
(function(){

// do stuff

})();
The sequence of )() could suggest that something happened before and somehow it constrict us to check if there are other 2 round brackets before those spotted at the end.
Furthermore, if we have an expression this is what we could write:

var something;

// other code

(something = function(){

// do stuff

})();
Again, unless we did mean that operation, maybe to avoid IE problems with named function expressions, those brackets outside the "wrap" could truly be considered ambiguous: was I trying to assign the expression result or the function itself?

something = (function(){

// do stuff
// return stuff

}());
There we have again a clear statement of what we were planning to do, isn't it?

Anonymous Assignment

We could think about some common pattern we can consider less error prone, and less ambiguous ... the first one is the classic assignment, performed for prototype properties, to avoid IE problems, or simply assign callbacks:

something = function(){};


Inline Invoke

We may agree that next one is the bets way to make an inline invoke non ambiguous:

something = (function(){}());

Same is if we are not returning anything, so that the expression will be called simply because we need a closure:

(function(){}());


Inline Constructor

This is not truly such common technique, but there is a massive difference if we use brackets or not.

var a = new (function(){
return Array;
}());
// true
alert(a instanceof Array);


var a = new function(){
return Array;
}();
// false
alert(a instanceof Array);
// a is actually the Array constructor
alert(a === Array);

The usage of new before an expression is something more suitable for ternary operator:

var o = new (typeof null !== "object" ? Object : String);

not particularly suitable for inline constructor concept.
This simply means, in my opinion, that if we meant to use the function as a Singleton, we should never put brackets around:

var Singleton = new function () {
var secret = "Singleton Baby!";
this.constructor = Object;
this.toString = function () {
return secret;
};
};

alert(Singleton);
// Singleton Baby!


As Summary

Earlier, I found the initial advice kinda redundant or superfluous, but I must admit it could make sense specially in weird cases, and this is why I have personally started to adopt it without feeling less readable at all.
Is there any other case where we could try to avoid expression ambiguity?

Monday, March 08, 2010

CommonJS - A YAGNI Based "require"

I am very busy these days with my last (hopefully) moving into my new and completely empty rented flat ... and while I am building home utilities and preparing my last post about A Better JS Class, with some extra case where common libraries fail with their parent implementations, I would like to quickly share this require function I wrote days ago but just recently came back in front of my eyes.

Why require

In CommonJS we have different techniques and agreement about how developers should structure/organize their namespaces and libraries.
The first common function adopted from CommonJS "followers" is the require one. This function aim is to load once, and runtime, a namespace, allowing scripts loaded via this function to define exported properties/variables or methods/functions.

// file main.js
var $ = require("jquery").$;

// file jquery.js
// let's imagine jQuery library has this piece of code inside
if ( typeof exports != "undefined" ) {
// export the library as dollar function
exports.$ = jQuery;
}


The require Function


var require = (function (
global, // global scope object (not necessary window)
cache, // object with loaded namespace to avoid reloads
exports, // variable name (better compression)
ActiveXObject // property name (better compression)
) {
/*!WebReflection:MitStyle*/
function request(namespace) {
// create the xhr object, no need to optimize
// this check is nothing compared with the time
// required to load and evaluate the resource
var xhr = new global[global[ActiveXObject] ? ActiveXObject : "XMLHttpRequest"]("Microsoft.XMLHTTP");
xhr.open(
// method
"GET",
// path replaced
(require.root || "") + "/" + namespace.replace(/\./g, "/") + ".js",
// synchronous
false
);
// send request
xhr.send(null);
// assign the runtime created export object
// with the required namespace
return (cache[namespace] = Function(
exports,
// the text will be evaluated in a global function
// it can register exported variables/methods
// simply writing:
// export.$ = {};
// so that require("mylib").$; will always
// point to the correct property
xhr.responseText + ";return " + exports
// be sure the function is executed
// with a global context (the this reference)
).call(global, {}));
}
// if namespace has been loaded already
// the associated export object will be returned
// otherwise the precedent function will be
// executed
function require(namespace) {
return cache[namespace] || request(namespace);
}
// the exposed function
return require;
}(this, {}, "exports", "ActiveXObject"));

Above piece of code fit into about 350 bytes once minified, less than 260 bytes gzipped ... sweet, isn't it?
Bear in mind if we need a root, we can simply add it via require.root = "./my/js/path"; without last slash after the final folder (e.g. require.root="." to load from the current one).

YAGNI In Details

For those unable to understand the acronym, YAGNI simply means "Ya ain't gonna need it".
The YAGNI behind my proposal could be summarized in this way:
  • server side frameworks have their own native require, no need to fully replicate it, it's already there
  • simply Ajax, if the browser does not load via other protocols and you are testing, enable file: via about:confing/strict or the local support for XHR
  • the most used case is the one we all know, require function will be there, as global one, and module object is not yet important (CommonJS is constantly updated as well)
  • A well organized namespace will improbably affect object properties (e.g. Object.prototype["my.name.space"] does not make much sense). No need to use hasOwnProperty, specially not the object itself one, since Object.prototype.hasOwnProperty could be redefined without problems and most probably this is an edge case more dangerous than the prototype["my.long.namespace"]

All these points are better considered in another version I did not know, the one from David Flanagan.
In any case, we should consider this valid point of view about require and JavaScript client, from Lucas Smith.
At least now we have more alternatives in the field, with this one that should simply bite others at least for size, and for common case reliability.
Enjoy!