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

Saturday, January 30, 2010

[ES5] Classes As Descriptor Objects

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 after that we can talk about the meaning of performances, right? Netbook should be able to surf without 100% of CPU usage, do you agree?)

The best part over all these years of wrong classical inheritance implementation is that with JavaScript.Next, aka ES5, the way we can define instances does not even require a function definition. Wanna know more?

Objects Extend Objects

It's that simple, we all know this is what happens in OOP Languages based over prototypal inheritance ... and since it is that simple ...

ES5 Classes As Descriptors

Or if you prefer, as definition objects. Yep! While every framework is using functions to create instances via new, in ES5 we could completely forget this pattern.

// class descriptor/definition
var MyClass = {
getValue:function () {
return this._value;
},
setValue:function (_value) {
this._value = _value;
}
};

// MyClass instance
var mc = Object.create(

// inherits from MyClass
MyClass,

// define privileged properties or methods
{
_value:{
value:"Hello ES5"
}
}
);

// Hello ES5
alert(mc.getValue());

Pretty cool, isn't it, but I am sure somebody is already arguing something like: "... and what about instanceof?"

instanceof

The instanceof operator checks if an object inherits from the implicit constructor prototype.
A common mistake is to think that instanceof is related to the function itself while it has nothing to do with it.

function A() {};
var klass = {};
A.prototype = klass;

var a = new A;

// true
alert(a instanceof A);

A.prototype = {};

// false
alert(a instanceof A);

function B(){};
B.prototype = klass;

// true
alert(a instanceof B);

Is it clear? instanceof works only with functions and only with those functions with an implicit prototype property, the default one, or specified as a generic object.

function A() {};
A.prototype = null;

var a = new A;

// throws: 'prototype' property of A is not an object
alert(a instanceof A);

To avoid above error, being JavaScript 99% dynamic, we could use a safer check, and for this example via isPrototypeOf:


function instanceOf(o, F) {
return !!F.prototype && F.prototype.isPrototypeOf(o);
};

function A() {};
var a = new A;

// true
alert(instanceOf(a, A));

Boring, slow, etc etc ... why don't we use directly our initial class description to understand if an instance is inheriting that class?

// using first example code
alert(MyClass.isPrototypeOf(mc));
// true

As alternative, we could use the global Object.getPrototypeOf method:

Object.getPrototypeOf(mc) === MyClass;

To be honest, for both easier scope resolution and semantic, I prefer the isPrototypeOf way. Furthermore, specially if the chain is deeper than 1 level, getPrototypeOf could generate false negatives while getPrototypeOf won't.

function A() {};
function B() {};
(B.prototype = new A).constructor = B;

var b = new B;

// true
alert(Object.getPrototypeOf(b) === B.prototype);

// false
alert(Object.getPrototypeOf(b) === A.prototype);

// both TRUE!
alert(B.prototype.isPrototypeOf(b));
alert(A.prototype.isPrototypeOf(b));

Accordingly, the best function to emulate an instanceOf function over objects or "classes" could be:


function inherits(o, __proto__) {
// (C) Mit Style WebReflection suggestion
return ((
typeof __proto__ === "function" ?
__proto__.prototype :
__proto__
) || {}).isPrototypeOf(o);
};

// test case
function A() {};
function B() {};
(B.prototype = new A).constructor = B;

var b = new B;

// true,true,true,true
alert([
inherits(b, A),
inherits(b, B),
inherits(b, A.prototype),
inherits(b, B.prototype)
]);


More ES5 Friendly Patterns

If we use what ES5 is bringing into JavaScript and via native execution speed, we may be interested into more "articulated" patterns to define "classes", or simply classes instances.

Object.defineProperties

First of all, as I have twitted already, please ignore that wrong suggestion about custom implementation.
The only place where all those checks could make sense is inside Object.defineProperty, and not twice in both defineProperties AND definePrperty, since if latter exists, why on earth we should try to emulate its internal checks?
If defineProperty does NOT exists, why shoud we try to emulate it without checks? I hope MDC guys will remove that nonsense from that page, I'd love to be sure developers get ES5 properly, good practices included.
Back in the topic, here there is an example:

function A(_value) {
// implicit init method
// where we define privileged proeprties/methods
Object.defineProperties(this, {
_value:{
value:_value,
// as example since it is false by default
enumerable:false
}
});

// and eventually we perform some task
};

// Class definition
Object.defineProperties(A.prototype, {
toString:{
value:function () {
return "" + this._value;
},
configurable:false
}
});

var a = new A(123);
alert(a); // 123

Does it make sense? We have more power via defineProperties and we can reuse, or share, objects across the whole library without any kind of problem.
One thing we should be ware about, is that A.prototype is always re-assignable, so if we try to define the A prototype property itself as non configurable we won't be safer anyway, it can be overwritten!

Dual Behavior: Factory Emulator


// when use strict will be enabled
// to obtain dual behavior (factory/constructor)
function A(_value) {
"use strict";
return Object.defineProperties(this || new A(_value), {
//... privileged definition
});
};


Dual Behavior Via Object.create


// Object.create way
function A(_value) {
// note that "this" may be useless, A() same of new A()
// inheritance chained in place
return Object.create(A.prototype, {
_value:{
value:_value,
enumerable:false
}
});
};

A.prototype = Object.create(A.prototype, {
toString:{
value:function () {
return "" + this._value;
},
configurable:false
}
});


Confused ???

I know I have started saying that theoretically we don't need anymore a single function to implement inheritance via ES5, but I bet those Java guys won't ever accept the fact JavaScript has no Classes and this is why I have suggested different patterns so that everybody could be happy about these ES5 features.

When Can We Start To Use These Features

Right now, in my opinion, including just one single vice versa project Object.js file, being careful about the target browser.
Unfortunately, and as usual, Internet Explorer is behind every other browser and some method cannot be perfectly emulated.
This is also why I have decided to show both defineProperties and create way, since IE defineProperties works only with DOM prototypes and global Window (or generally speaking only with natives and not with object) so that create could be used without problems, so far avoiding get/set and considering that configuration properties may not be respected.
I know this is crap, but until IE9 or the day we'll finally decide to drop this browser support, there's not that much we can do: annoying!

P.S. to test all these natively, we can use a WebKit nightly build.

Monday, January 25, 2010

The JavaScript _super Bullshit

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:
  1. an instanceof its Class
  2. only that method will be executed, it is possible to call other super/parent accordingly with the hierarchy
  3. if the instance Class overrides a parent method, when this will be executed via super, the invoked "extra" method will still be the one defined in the instance class and nothing else

// Classic OOP Behavior, a simple PHP 5 example
class A {
public function __construct() {
echo 'A.__construct', '<br />';

// this will call the B method indeed
$this->hello();
}
public function hello() {
echo 'A.hello()', '<br />';
}
}

class B extends A {
public function __construct() {
// parent invocation, this has nothing to do with the instance
parent::__construct();
echo 'B.__construct', '<br />';
}
public function hello() {
echo 'B.hello()', '<br />';
}
}

new A;
// A.__construct
// A.hello()

new B;
// A.__construct
// B.hello()
// B.__construct

Even if most frameworks respect above behavior, there is still somebody convinced that _super/parent is something truly simple to implement, often replacing this references runtime without taking care of multiple hierarchies, more than a super, method specific super, and on and on ...
In few words, if above behavior is respected, and the best test case is with more than 2 extended classes, we could think we are half way there ... isn't it?

John Resig on Simple JavaScript Inheritance

John called it simple, and it is simple indeed. Inheritance in JavaScript has a name: prototype chain.
John did a good job for those few bytes, the runtime replaced method is temporarily the called one, so other methods will be invoked as expected.
Everything perfect? Not really, some "tiny little problem" could occur if for some reason something goes wrong.

var A = Class.extend({
init: function () {
document.write("A.constructor<br />");
},
hello: function () {
throw new Error;
document.write("A.hello()<br />");
}
});

var B = A.extend({
init: function () {
this._super();
document.write("B.constructor<br />");
},
hello: function () {
this._super();
document.write("B.hello()<br />");
}
});

setTimeout(function () {
alert(b._super === A.prototype.hello);
// TRUE!
}, 1000);
var b = new B;
b.hello();

This is what I mean when I talk about DPP, something goes wrong? The instance will be messed up.
Don't even think about a try catch for each method invocation, this will make your application extremely slow compared with everything else.
In any case, 5 stars for its simplicity, but think before you decide to use _super in any case.

MooTools Way

Update My apologies to MooTools team. I had no time to re-test a false positive and MooTools is partially secured behind its parent call. However, my point of view about chose magic is well described at the end of this post comments, enjoy.

The Prototype Way

So we have seen already _super and parent problems, both wrongly attached into the instance, but we have not seen yet the Prototype way: the $super argument!

var A = Class.create({
initialize: function () {
document.write("A.constructor<br />");
},
hello: function () {
throw new Error;
document.write("A.hello()<br />");
}
});

var B = Class.create(A, {
initialize: function ($super) {
$super();
document.write("B.constructor<br />");
},
hello: function ($super) {
$super();
document.write("B.hello()<br />");
}
});

setTimeout(function () {
alert(b);
// nothing to do
}, 1000);
var b = new B;
b.hello();

Eventually, Prototype library got it right, YES!!!
While every other is associating super to the instance, Prototype understood that super has nothing to do with the instance.
Every method which aim is to override the inherited one must have a $super argument, if we want a limitation but finally the only implementation that does not break anything, whatever happens in the super call.
This is correct, the instance is temporarily injected into the super method and nothing else. No self referencing, no run-time assignments that could break, simply the method, that will host for a call that instance.
Every other method will be wrapped in order to bring the current instance in the super one and in this way we can consider our code somehow safer, the whole application won't break if something goes unpredictably wrong!

Still Something To Argue About

While I have never thought that Prototype got it absolutely right, I must disagree about its Class implementation.
It's that simple, I have already said it, in JavaScript Classes are functions!
Accordingly, why on earth Class should be an object?

function Class(){
return Class.create.apply(null, arguments);
};
Object.extend(Class, {
// the current Class object
});
Class.prototype = Function.prototype;

With a ridiculous effort, Prototype library could be the first one to implement a proper Factory to create classes!

// valid, for OO "new" everything maniacs
var A = new Class(...);

// still valid, alias of Class.create
var B = Class(...);

// explicit Factory
var C = Class.create(...);

// there we are!
alert([
A instanceof Class, // true
B instanceof Class, // true
C instanceof Class, // true
A instanceof Function, // of course
B instanceof Function, // of course
C instanceof Function // of course
]);


How Things Work "There"

The second thing I must disagree about Prototype is the way arguments are retrieved.
The king of public prototypes pollution framework does not cache the Function.prototype.toString to avoid overrides and/or redefinition:

function Fake($super){};
alert(Fake.argumentNames());

Function.prototype.toString = function () {
return this.name || "anonymous";
};

// throws an error
// alert(Fake.argumentNames());

// Fake is a first class *Object*
Fake.toString = function () {
return "[class Fake]";
};
// throws an error
//alert(Fake.argumentNames());

Fake.toString = function () {
return "function Fake(){return Fake instances}";
};
// empty string
alert(Fake.argumentNames());

Are you kidding me? Let's try again:

Function.prototype.argumentNames = (function (toString) {
return function() {
var names = toString.call(this).match(/^[\s\(]*function[^(]*\(([^\)]*)\)/)[1]
.replace(/\s+/g, '').split(',');
return names.length == 1 && !names[0] ? [] : names;
}
})(Function.prototype.toString);

4 out of 4 successful arguments parsing, rather than errors, problems, etc etc, for a framework that is already obtrusive, but at least in this case did not consider obtrusive code at all ... please fix it!

Inevitable Unportable

Finally, since the Prototype way requires wrappers and first argument injection, attached methods become instantly not portable anymore.
If we define a subclass and we would like to recycle its method somewhere else, we are trapped by the replaced, wrapped, injected $super argument.
Unfortunately this is the worst side effect for something that is actually not even close to classic OOP ... but we need to accept this compromise, or we simply need to better understand JavaScript, isn't it?

As Summary

This post does not want to be a "blame everybody for free" one, this post simply shows why I have written my Class implementation and why I do prefer explicit calls (somebody called them hard-coded) to super, shared, parent, whatever, inherited prototypes, as is for any other function we need in the middle of a session. JavaScript is like that, every function could be called without any warning somewhere with a different "this" reference and this is actually one of the most interesting and beauty part of this language.

I hope I have been able to give hints to both libraries authors, just 3 in this case, and specially to developers, those that copya and paste code trusting the source but unable to perform these kind of tests, and those convinced that JavaScript OOP and this._super is cool and it makes sense. As you can see, it does not, logically speaking first, and technically speaking after.
Last, but not least, all these wrappers simply mean less performances, even if we are talking about small numbers (a whole framework/libary based over these small numbers can easily become a pachyderm, seconds slower than many others).

Saturday, January 23, 2010

Better JavaScript Classes

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 library
new Class({}) instanceof Class;
// FALSE, since Class returns a function
// and not the created instanceof Class

Above misconception about what a Class is and how meaningless and redundant is the new keyword in latter case is truly annoying me!
The reason developers want "Classes" in JavaScript is because they think their OOP knowledge is better than what JS already offers, so why on earth they should create and use such hybrid nonsense?

A Class IS A Function

Nothing more and nothing less. The fact we would like to use that function to create and initialize instances is just how every Functions work, or if we prefer, a developer convention and a quick way to chain a prototype into an object.
Since a Class is a Function, and whatever "new Class()" will always be an "instanceof Function", Class.prototype should be exactly the Function.prototype one, so that nobody can ever say again: "Look, I have created a Class" ... no bullshit Sherlock, you created a Function!

How To Define A "Class"

If we think about classical OOP languages, the only way to use a Class is to define it indeed. In few words, if the plan is to use a new Class() approach, how about a mandatory Class definition Object ?

// the most basic Class implementation
function Class(
// Class definition object: mandatory
__proto__
) {
// define the "Class"
// if the definition object has a constructor property
var Class = __proto__.hasOwnProperty("constructor") ?
// use it ...
__proto__.constructor :
// otherwise create one and assign it
(__proto__.constructor = function () {})
;
Class.prototype = __proto__;
return Class;
}

// we already said that a Class is simply a function ...
Class.prototype = Function.prototype;

Above code is basically all we need to start using new Class(definition) approach:

// class creation via definition object
var Person = new Class({

// this is our Person constructor
constructor: function (name) {
if (name) {
this.setName(name);
}
},

// this is a public property
name: "anonymous",

// this is a public method
setName: function (name) {
this.name = name;
}

});

Person instanceof Class; // true
Person instanceof Function; // ... as well

var dunno = new Person;
dunno instanceof Person; // true
dunno.name; // anonymous
dunno.constructor === Person; // true

I think this approach is as elegant as simple, but there is still a lot to consider about it.

A constructor IS An Implicit Init Method

I don't really know "when" it started and I am not sure about "why", but lots of libraries use this extra call to init/initialize/initializator/WTinitF method. If we think about this approach, it's like this:

// the JavaScript way
var a = [];

// the init way
var a = [];
a.init();

Now, think that for every created instance, rather than simply use the constructor for what it is, a method able to initialize an instance as is for basically every OOP language, we need to access to the instance chained prototype to execute a second init ... not sure what you think about it, but this sounds a bit redundant to me ...
A Class constructor is already able to initialize an instance, that is simply why I have decided to be semantic and use just the constructor method as is rather than an extra init call.

A constructor Must Be Unique

The definition approach is something good in any case, but above implementation does not consider one of the best features in JavaScript: the context injection.
If we would like to reuse common methods, as example for a mixin or a hybrid prototype, initial suggestion is not enough.
The moment we use the same constructor to initialize a variable, we are already stuck. Even worst, we cannot reuse the same definition object to partially define one or more classes with common methods or initialization.
How to solve this? We need to chain the definition object in order to be able to extend the created Class.prototype for everything we need.

// chained Class definition example
var Class = (function () {

// the public Class function
function Class(__proto__) {
// the created "Class"
function Class() {
// initialize the instance via original constructor
__proto__.constructor.apply(this, arguments);
}
// assign the prototype ...
Chain.prototype = __proto__ || (__proto__ = {});
// ... and create the chain, assigning the right constructor
Class.prototype = new Chain(Class);
return Class;
}

// runtime __proto__ chain with right constructor assignment
function Chain(Class) {
this.constructor = Class;
}

Class.prototype = Function.prototype;

return Class;

})();

We are still far away from a proper solution, at least we can now reuse a generic function to initialize one or more instances and we can reuse definition objects

var commonDef = {
constructor: function (name) {
if (name) {
this.name = name;
}
},
name: "unknown"
};

var Named = new Class(commonDef);
// this operation won't change commonDef object
Named.setName = function (name) {
this.name = name;
};


var Person = new Class(Named.prototype);
// this operation wont change Named.prototype
Person.prototype.getName = function () {
return this.name;
};

Thanks to prototype chain we are now able to extend directly another prototype, so that new Person, as example, will be instanceof Named too.

Don't Mix Class Definitions And Prototypes

While it could look good, the latter example has truly a bad design.
A Class definition should be a concept a part. If we use another Class.prototype to define a new Class we are mixing definitions with "defined" concept.
To extend or inherit from another object there must be a specific method.
To better explain myself, let's consider this simple PHP example:


class A {
// here we define the class
public function doStuff() {
}
}

class B extends A {
// we are extending another class
// but we are still defining here class B structure
public function __construct() {
}
}

If we pass directly a Class.prototype as definition, we are basically doing this, rather than what I have already showed:

class B extends A {}

Can we see the difference? B extends A and nothing else, there is no definition for B, everything is just like A.
OK, in JavaScript we can add and remove properties and methods from a prototype or a single instance in whatever moment, but aren't we trying to emulate somehow classic OOP paradigm? So let's agree that if we like this approach, prototypes must be untouchable after Class definition, and defined prototypes mustn't be used as Class definition ... do we agree?

Function.prototype.extend FAIL

I am the first one in error, I have tried to defined dunno how many times a proper Function.prototype.extend in order to make every function extensible.
The problem, specially in this case/approach, is that functions are functions, while Classes are Classes. If we make a generic "extend" method available for any kind of function, even those never used to create instances, we are simply polluting without a valid reason a shared prototype: shared between classes and functions.
Moreover, the fact a Class is extending another one should be instantly recognizable, and not something that could happen in the middle of a generic session, do you agree?
In few words, some common approach is not truly readable/reasonable:

function B() {
// something happens here
};
// lazy extend, could happen everywhere
// even with functions such Math.max, kinda nonsense
B.extend(A);
B.prototype = {...};

// new Class pattern
var C = new Class({
// long definition object
})
// we need to scroll till the end to understand
// if C.prototype is chaining another one
.extend(B)
;

If we compare again with precedent PHP snippet, or every other OOP language where extends is basically the first thing we can understand about a class, I think nobody should ever use above pattern in JavaScript: it's cool, it's dynamic ... but it's absolutely wrong as well if we are trying to bring classic OOP approach into this language!

Only Explicit Extend Via Definition Object

At least for this topic, most common libraries are already implementing what I am talking about, which is something like this:

var Man = new Class({

// first thing ever into definition object
extend:Human,

// optional constructor ir simply
// the rest of the definition
gender:"male"

});

The fact extend must be explicit is simple: nobody should be able to pollute Object.prototype adding an extend method/property, if we recycle objects we don't want to extend automatically any inherited extend from internal chains.

Public Statics

Almost the last piece of the puzzle, the ability to add via definition public static properties or methods.
This could be another special property name, used like this:

var File = new Class({
statics:{
exists:function (fileName) {
// some cool code here
return found;
}
},
constructor: function (fileName) {
this.name = fileName;
},
exists: function () {
return File.exists(this.name);
}
});

var fileName = "index.html";
var index = new File(fileName);

// it should be always true
File.exists(fileName) === index.exists();


Class.definition

I am trying to keep writing semantic code so I guess the last piece ever to add into the run-time created class is simply one: the definition object.
For both introspection and tricky code, I think it's a good idea to be able to retrieve the definition object. It could be reused, it could be analyzed, there are several things that could let us think: how to get back that object?
Well, since the extremely useful __proto__ property is not standard, the only way to retrieve that object is to associate directly to the Class, being its definition, and via definition property name. Is there anything more semantic and logic than this?

var def = {what:"ever"};
var MyClass = new Class(def);

MyClass.definition === def; // true

Now we can say we have everything!

this._super bullshit

Don't get me wrong, I do appreciate the effort every framework is putting in order to have a nice way to retrieve a super method, if any, but what we need to understand is that:
  1. _super, parent, whatever it is, requires to be portable for each parent "level", not just one
  2. to make first point possible, _super requires a lot of initial parsing, wrapping, and runtime substitutions, an inevitable performances bottleneck, as showed in my old tests
  3. wrappers are anonymous and all equals, almost impossible to debug
  4. wrappers could fail, causing disasters if the "super" does not fallback into the original one for that level
  5. try catch for super are performances killers, at the same time the best way to avoid disasters
  6. wrappers could cause infinite loops, if super is not handled properly
  7. super/parent is not an instance related property!!!
The latter point is the one that should suggest us to think about "super" misconception.
In classical OOP the super/parent keyword is related to the current method, it is never an instance property.
When we need "super" we are talking about the super definition of the overridden method, if any, or another one up to the initial ring of the prototypal chain.
In few words, super has nothing to do with the instance, but for JavaScript nature, the simplest way to change runtime its reference, is to attach it to the instance.
Last, but not least, I have personally encountered problems, dunno how many times, with a whole stack or super wrappers without being able to understand which method was failing and where!
I am pretty sure that developers perfectly know what I am talking about, so while this._super can be "cool", have we never thought how much better explicit injections could be?

var A = new Class({
doStuff: function () {
this.where = "A";
}
});

var B = new Class({
extend:A,
doStuff: function () {
// zero ambiguity, zero wrappers
// best performances + fast debug
A.prototype.doStuff.call(this);
// if some error occurs here
// we know where it did, rather than a wrapper
this.where += "B";
}
});

Furthermore, while in classic OOP super/parent is usable for properties as well, I have never seen a proper implemntation for this in any framework.
As summary, while "super" or "parent" is something truly natural for classic OOP developers, there is no easy way to implement it properly in JavaScript, specially because if the same function can be used as method for 3 different classes, as example, the keyword super there will completely lose its meaning, basically the reason the only way to implement it, is to attach, substitute, and execute, runtime, via instances, rather than proper methods definition lookups. This is why my Class implementation does not provide such problematic "solution" for lazy developers.

WebReflection Class


var Class = (function () {

/*!
* JavaScript meaningfull Classic OOP Class Factory
* @author Andrea Giammarchi
* @license Mit Style
*/

/**
* Public exposed Class function
* @param Object the Class definition
*/
function Class(definition) {

// create the function via named declaration
function Class() {}

// find out if this is an extend
var $extend = hasOwnProperty.call(definition, "extend");

// temporary shortcut for inherited statics
var $;

// reassign the Class if there is a constructor ...
if (hasOwnProperty.call(definition, "constructor")) {
// wrapping it for faster execution
Class = constructor(definition.constructor);
}

// assign inherited public static properties/methods, if defined in the extend definition
if (
$extend &&
hasOwnProperty.call($ = definition.extend, "definition") &&
hasOwnProperty.call($ = $.definition, "statics")
) {
extend.call(Class, $.statics);
}

// assign public static properties/methods, if defined
// eventually overwrite inherited statics
if (hasOwnProperty.call(definition, "statics")) {
extend.call(Class, definition.statics);
}

// assign the prototype accordingly with extend
($extend ?
// chain the prototype extending it with the definition object
extend.call(Class.prototype = create(definition.extend.prototype), definition) :

Class.prototype = create(definition)
)
// be sure the constructor is the right one
.constructor = Class
;

// static public definition
Class.definition = definition;

// return the created class
return Class;
}

// wrap the constructor via closure
function constructor(constructor) {
// creating a named declared Class function
function Class() {
// return in any case for dual behaviors (factories)
return constructor.apply(this, arguments);
}
return Class;
}

// extend a gneric context via __proto__ object
function extend(__proto__) {
for (var key in __proto__) {
if (hasOwnProperty.call(__proto__, key)) {
this[key] = __proto__[key];
}
}
return this;
}

// trap the original Object.prototype.hasOwnProperty function
// as shortcut and hoping nobody changed it before this file inclusion ...
var hasOwnProperty = Object.prototype.hasOwnProperty;

// quick/fast Object.create emulator, if not in ES5
var create = Object.create || (function () {
function Object() {}
return function (__proto__) {
Object.prototype = __proto__;
return new Object;
};
})();

//* optional standard "for in" for Internet Explorer
// it could be removed if we don't define "magic mathods" in definition objects
// Internet Explorer does not enumerate properties/methods
// with name present in the Object.prototype
if (!({toString:null}).propertyIsEnumerable("toString")) {
// if this happens, to make the extend consistent
// we need to force Object.prototype names
extend = (function ($extend) {
function extend(__proto__) {
for (var i = length, key; i--;) {
if (hasOwnProperty.call(__proto__, key = split[i])) {
this[key] = __proto__[key];
}
}
// execute the original extend in any case for other properties/methods
return $extend.call(this, __proto__);
}
// constructor is not in the list since there is a re-assignment in any case
var split = "hasOwnProperty.isPrototypeOf.propertyIsEnumerable.toLocaleString.toString.valueOf".split(".");
var length = split.length;
return extend;
})(extend);
}
//*/

// a Class is a Function and nothing else
Class.prototype = Function.prototype;

return Class;

})();

A simple test case:

var A = // base class
new Class({
constructor: function () {
alert("A");
},
toString: 123
})
;

var B = // extended class
new Class({
extend:A,
constructor: function () {
A.call(this);
alert("B");
},
toString: 4
})
;

var b = new B;
// 4, true, true, true in every browser
alert([b.toString, b instanceof A, b instanceof B, b.constructor === B]);


Personal Thoughts

What I don't like is that extend, as statics, become part of the prototype as well. Unfortunately I decided that these words should be kinda reserved in order to speed up Classes creation.
At the same time, Classes creation is something performed once and never again, so I may decide to change in the future the way I define the prototype, simply looping via "for in" and attaching properties. This could cause some sort of problem with truly inherited stuff, so right now I guess this is it.

As Summary

My Class implementation does not probably bring anything new in the panorama but what it does, it does it properly. The definition object has precedence over inherited properties/methods. Super or extra methods calls should be explicit, avoiding redundant wrappers, improving performances, and making debug easier. Constructors, if present, are used as instance initializers, as it has always been in classic OOP. Every definition could be wrapped in a closure and returned, in order to have shared private properties or methods and Classes are finally instanceof Class, or better, are simply functions.

Monday, January 18, 2010

Good Old And Common JavaScript Errors

... I won't write any introduction, but I'll let you comment, OK?

for loops (plus ++i)



for(i = 0; i < 10; i++){}
// global i defined

for(var i = 0; i < something.length; i++){}
// cache the length if it won't change during the loop
// associate once only under certain conditions to speed up

for(var i = 0; i < 10; ++i) {}
// there is absolutely nothing wrong in above loop

Few people told me something like: "doode, if you use ++i at the end you need to write i < 11 'cause i will be 1 inside the loop" ... basically the for loop has been rarely understood, let me try again:

// directly from C language, 1972
for(

// optional inline declaration, coma accepted for more vars
;

// optional condition to verify
// if undefined, it loops until a break is encountered
// this condition is performed BEFORE the first loop
// if false, the loop will never be executed
;

// optional POST operation, it will never be executed
// if the condition is false, "", 0, or null
// it is executed in any case AFTER the loop, if any
){};


// example
for(var i = 0; i < 1; ++i){
// one single execution
// i will be 0 here
};
// i will be 1 here

The reason ++i is preferred over i++, whatever Google go language decided about it, is that i++ and ++i are totally different and you need to understand when, or why, you need i++ or ++i.
While ++i increments directly the variable, returning the variable itself, if numeric, i++ returns a NEW variable with the precedent value AND it increments the i var as well.
Pure JavaScript Example

function Num(value) {
this.value = value;
};
Num.prototype.valueOf = function () {
return new Num(this.value);
};
Num.prototype.toString = function () {
return "" + this.value;
};

var a = new Num(0);
var b = a++;
alert(a); // 1
alert(b); // 0
alert(a == b); // false

// again

var a = new Num(0);
var b = ++a;
alert(a); // 1
alert(b); // 1
alert(a == b); // true

It does not matter if speed speaking, the difference is "not that consistent", it matters that we are programmer, and if two things mean different things, we want to understand them, am I wrong?

Already defined variables, and scopes


Another piece of code you can find around the net, is this:

// something defined globally
var num = 1;

(function () {
// try to set a default
var num = num || 0;
})();

Above code will never work, and it's the ABC about scope and functions.
It's exactly like this:

// something defined globally
var num = 1;

(function (num) {
// now try to find the global num without this. or window. ...
})();

Same is for arguments:

function A() {
// this is actually correct since arguments shares same scope
// no shadowing in this case, thanks to qfox
var arguments = arguments || [];
};

What we need to understand, is that next code is ALWAYS true:

var u = 123;
(function () {
var u = (typeof u === "undefined");
// u is TRUE!!!
})();

The moment we define a scoped variable, it has precedence over whatever outer scope: bear in mind!!!

new Array, new Object


I can't wait the day people will stop to prefer this code:

var a = new Array(); // NOTE: no length/elements specified
var o = new Object(); // NOTE: no object to wrap/convert

rather than:

var a = [];
var o = {};

There are no excuses at all. First of all, the "new Array/Object" way is unsafe, since both constructors can be easily redefined/wrapped, as explained ages ago in many different security related JavaScript issues.
Moreover, we have both more bytes to digest and reduced performance, and a compiler/minifier that is so cool that will change automatically new Array into [] will simply potentially break our code so we cannot even rely improvements with production code.
So ... PLEASE DON'T!

... and new Function ...

Hey, Java guys, please answer this question:
Would you ever use in your Java life a factory method via "new" ???
Seriously, I don't get it ... let's go one step back ...

The Meaning of Factory


The essence of the Factory Pattern is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."


JavaScript Functions Behavior

If a JavaScript function returns a primitive value such: "string", true, false, null, int, double, new function will return an instanceof that function, overriding the returned result.
Same is for no returns, or return undefined.
If a JavaScript function returns an object, the usage of new is completely redundant and useless.

Array, Function, Object, and RegExp are Factory!!!



var a = Array();
var b = new Array();
var c = [];
[
a instanceof Array,
b instanceof Array,
c instanceof Array
]; // true,true,true


Boolean, Date, Number, and String are both primitive casts and Object constructors!!!



var a = 1;
var b = Number("1");
var o = new Number(1);
a === b; // true
a === o; // false
a == o; // true
a instanceof Number; // false
o instanceof Number; // true
typeof a; // number
typeof o; // object

As summary, and again, please repeat with me:
If a JavaScript function returns a primitive value such: "string", true, false, null, int, double, new function will return an instanceof that function, overriding the returned result.
If a JavaScript function returns an object, the usage of new is completely redundant and useless.


new Class(whatever) === new Factory(whatever)!!!


This is the most misunderstood part that seems so logical but does not make sense at all. 99.9% of cases and in different libraries we can find the classic call to new Class to create what people think is a Class in JavaScript (in few words, to populate the prototype of a runtime created function).
Wait a second ... did I just say: to create a Class?
Uhm ... so, we don't create an instance ... we create a class ... uhm again, so, we are using a Factory, isn't it? :zizi:

Function.createClass() would be hundreds of times more correct, logically speaking, but we all like the new Class, right?
Well, I wonder how many Java Gurus create they Java classes via new Class() on daily basis ... what? You have to define a class, not to create one? ... oh, REALLY???
MooTools use new Class to create runtime functions, parse the configuration object in order to populate the created function prototype, extending it with a completely useless this, that could be simply Class.prototype without useless runtime instanc`es creation for each Class, to finally return a function that is not instanceof Class ... not even primitives values in JavaScript are that ambiguous, isn't it?

new Class({}) instanceof Class; // FALSE!!!

MooTools is simply one in the ocean of libraries that use this misconception to create Functions, not Class, Function.
Considering that JavaScript has no classes, something apparently unacceptable for GWT and friends maniacs that absolutely need to compile their Java application inevitably into a prototypal based programming language as JavaScript is, thinking they have more power over the application, I agree that classic OOP is something so intrinsic in the IT panorama, that it will never die and it could make somehow things simpler for newcomers into JavaScript. OK, I am with you ... can we at least agree about the fact new factoryMethod does not make sense at all?

Logically Speaking ...


Rather than nonsense why don't we simply respect JavaScript native behavior?
If we consider native constructors behaviors such Boolean, Number, or String, I have already described what's up if we use new or not.
There is a massive difference between new and not new ... so why don't use the same behavior for Funciton?

// example
var f = Function("return 'function'");
alert([f instanceof Function, f()]);
// true,function

var f = new Function({toString:function(){return "instance"}});
alert([f instanceof Function, new f()]);
// true,instance

In few words we can easily think about Function as a primitive function creator AND as a function instances creator, those that we'll love to use to instantiate our application objects. Does it sound really that silly?

var Function = (function (Function) {
// (C) WebReflection Mit Style

// Class with private constructor
function constructor(constructor) {
function Class() {
constructor.apply(this, arguments);
};
return Class;
};

// Class creator
function Class(__proto__) {
function Class() {};
if (__proto__) {
if (hasOwnProperty.call(__proto__, "constructor")) {
Class = constructor(__proto__.constructor);
};
(Class.prototype = clone(__proto__)).constructor = Class;
};
return Class;
};

// special Function
function $Function(arguments, body) {
return this instanceof Function ?
Class(arguments) :
body == null ? Function(arguments) : Function(arguments, body)
;
};

// private variables
var
hasOwnProperty = Object.prototype.hasOwnProperty,
clone = Object.clone || (function () {
function clone() {};
return function (__proto__) {
clone.prototype = __proto__;
return new clone;
};
})()
;

// public static explicit factory
$Function.create = Function;
$Function.createClass = Class;

$Function.prototype = Function.prototype;

return $Function;
})(Function);

Here we are, and the best thing is that we can extend the prototype chain simply passing another prototype as configuration object.

function A(){};

var B = new Function(A.prototype);

alert(new B instanceof A); // true

Moreover, since whatever library will use a Function to create other functions, but since most of the time the new Class won't return an instanceof Class, with my suggestion whatever created "Class" will simply inherit Function.prototype.methods OR, if we want to add custom public methods, we can always do it later.
Finally, with a simple closure, we can still be semantic, and define private methods:

var MyClass = new Function((function () {
function set(value) {
this.value = value;
};
return {
constructor:function (value) {set.call(this, value)},
get:function () {return this.value}
};
})());

var o = new MyClass(123);
alert(o.get()); // 123

Now it's your turn, feel free to comment the path I followed, and give me other suggestions/common errors, if you remember any ;)

Update I almost forgot one of the most famous/silly one ...

Arrays "for in"



var a = [];
a[1] = 1;
a[0] = 0;

// global key defined
for(key in a);

// key will be first 1, then zero, in Internet Explorer and Opera
for(var key in a);

Another common mistake is to think that "for in" is good for arrays.
First of all the iteration order is unpredictable, there is no rule about "for in" iteration (or if any, nothing that is standard, cross-browser speaking) plus it's way slower than a normal iteration via length. Please DON'T!!! In this case as well.

Tuesday, January 12, 2010

ActionScript 2.0 to JavaScript Bridge

As discussed in my new year Ajaxian post, the Flash Player could provide some truly good info about the current user.
I have tried before to create a sort of "perfect bridge" to actually drive ActionScript directly via JavaScript.
Unfortunately, the layer added by the ExternalInterface is not light at all and things would move so slowly that it won't be worth it.
While in my post comments I have showed an example about how it is possible to export info from ActionScript to JavaScript, what I am describing right now is a sort of "general purpose bridge" to bring, statically and stateless, whatever info we need/want from whatever ActionScript 2.0 file/library we like, starting from the root.

Basic Example



<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>AS2Bridge by WebReflection</title>
<script type="text/javascript" src="AS2Bridge.js"></script>
</head>
<body>
<script type="text/javascript">

// override defaults showing the SWF
new AS2Bridge({width:320, height:200, style:""}).onload = function(){
var System = this.retrieve("System");
window.console && console.log(System);
setTimeout(function () {
System.showSettings();
}, 1000);
};

// another movie, an hidden one, just to retrieve some global AS 2.0 property
new AS2Bridge().onload = function(){
var _quality = this.retrieve("_quality");
window.console && console.log(_quality);
};

</script>
</body>
</html>

The AS2Bridge constructor creates each time, and if necessary, an instance related to the current ActionScript 2.0 global scope.

Single Method API: retrieve

Each instance will have a couple of public static properties, as is for example its related object id, plus a single public method:
self.retrieve(namespace:String):Object

Above method accepts a generic namespace string, which is basically the whole path, starting from the root, that will be exported.
This string can point to a property, a generic object, or even a function or method ... does it sound interesting?
As example, it is possible to export the whole System public static object:

var System = this.retrieve("System");

or just one part of it:

var playMusic = this.retrieve("System.capabilities.hasAudio");


The ActionScript 2.0 Code


(function ():Void {
/*! (C) Andrea Giammarchi - Mit Style License */

/** dependencies */
import flash.external.ExternalInterface;

/**
* executes a function and returns its exported value
* @param Number the registerd callback to exec
* @param Array arguments to send
* @return String exported result via callback
*/
function exec(i:Number, arguments:Array):String {
return callback[i].apply(null, arguments);
};

/**
* evaluates a namespace and exports it
* @param String a generic namespace to retrieve
* @return String exported namespace or one of its properties/methods
*/
function retrieve(key:String):String {
return export(eval(key), self);
};

/**
* Exports a generic object injecting its parent scope.
* @param Object generic property, value, method, or namespace to export
* @param Object parent to inject if a method is encountered ( e.g. (o = showSettings).call((p = System)) )
* @return String exported Object, the first argument, JavaScript compatible
*/
function export(o:Object, p:Object):String {
var type:String = typeof o;
switch (true) {
case o === null:
case type === "number":
case o instanceof Number:
if (isNaN(o)) {
return "null";
};
case type === "boolean":
case o instanceof Boolean:
return "" + o;
case type === "function":
case o instanceof Function:
return "function(){return " + bridge + ".__eval__('return '+" + bridge + ".__swf__.AS2Bridge__exec__(" + (callback.push(
function ():String {
return export(o.apply(p, arguments), p);
}
) - 1) + ",Array.prototype.slice.call(arguments)))()}";
case type === "string":
case o instanceof String:
return 'decodeURIComponent("' + escape("" + o) + '")';
case o instanceof Array:
for (var a:Array = new Array(), i:Number = 0, length:Number = o.length; i < length; ++i) {
a[i] = export(o[i], a);
};
return "[" + a.join(",") + "]";
case o instanceof Date:
return "new Date(" + o.getTime() + ")";
case o instanceof Object:
var a:Array = new Array();
var i:Number = 0;
for (var key:String in o) {
a[i++] = key + ":" + export(o[key], o);
};
return "{" + a.join(",") + "}";
default:
return "undefined";
};
};

/**
* Stack of stored callbacks encountered during exports.
* @private
*/
var callback:Array = new Array();

/**
* _root alias
* @private
*/
var self:Object = this;

/**
* String shortcut to use to point to the current bridge object (passed via query string or FlashVar)
* @private
*/
var bridge:String = "AS2Bridge.__register__[" + self.AS2Bridge__index__ + "]";

/**
* unobtrusive exposed callbacks
*/
ExternalInterface.addCallback("AS2Bridge__exec__", this, exec);
ExternalInterface.addCallback("AS2Bridge__retrieve__", this, retrieve);

/**
* JavaScript initialization
*/
ExternalInterface.call("eval", bridge + ".__init__&&" + bridge + ".__init__()");

}).call(this);

// optional stop to avoid loops if/when necessary
stop();

Thanks to a single closure, this snippet is desgned to work as stand alone, or as "general purpose no conflict plugin". In few words, whatever happens in the SWF it is always possible to retrieve a namespace/property/method and it is always possible from the SWF to call JavaScript:

// it is possible to call any public function without problems, e.g.
ExternalInterface.call("eval", 'alert("Hello from SWF")');


The ASBridge Constructor


if (typeof AS2Bridge !== "function") {
/*! (C) Andrea Giammarchi - Mit Style License */
var AS2Bridge = function (options) {
var index = AS2Bridge.__register__.push(this) - 1;
if (options) {
for (var key in options) {
this[key] = options[key];
};
};
this.id += index;
this.src += "?AS2Bridge__index__=" + index;
document.write(document.body ? this.__swf__() : "<body>" + this.__swf__() + "</body>");
};
AS2Bridge.__register__ = [];
AS2Bridge.prototype = {
constructor: AS2Bridge,
id: "__AS2Bridge__",
src: "AS2Bridge.swf",
style: "position:absolute;top:-10000px;left:-10000px;",
width: 1,
height: 1,
retrieve:function (key) {
return this.__eval__("return " + this.__swf__.AS2Bridge__retrieve__(key))();
},
__eval__:Function,
__init__:function(){
this.__swf__ = window[this.id] || document[this.id];
this.__init__ = null;
if (this.onload) {
this.onload();
};
},
__swf__:function () {
return ''.concat(
'<object type="application/x-shockwave-flash" ',
'style="', this.style, '" ',
'id="', this.id, '" ',
'width="', this.width, '" ',
'height="', this.height, '" ',
'data="', this.src, '">',
'<param name="movie" value="', this.src, '" />',
'</object>'
);
}
};
};

I am sorry I had no time to put proper comments, but I think it is simple enough to understand what's going on there.
There are defaults options, plus an horrible document write which aim is simply the one to put the SWF in place avoiding body problems.
Anyway, AS2Bridge would like to be after the head element, possibly inside the body ... the important thing is that it works, so why bother? ;)

The Whole Demo

With 908 bytes of cacheable SWF, and a ridiculous sice for the minified and gzipped JavaScript file, it is possible to test all I have said directly here.

Integration

ActionScript 3 a part, and would be nice to have time to create a bridge for it as well, it is possible to copy and paste in the root of whatever project my AS2.0 code in order to bring ActionScript to JavaScript export capability everywhere.
... told'ya it was something interesting, or maybe not ...

Monday, January 04, 2010

Flash Satay Revisited

The most famous and W3 friendly technique to serve an SWF has been described in this excellent A List Apart Article ages ago. Unfortunately there are few problems with that technique, and being Flash Player still widely adopted, plus nobody has created yet a HTML5 friendly Satay method, here I am with this proposal/suggestion.

Satay Problems

There are at least a couple of problems with the good old Satay method:

  1. double SWF request, performed by almost every browser

  2. SWF impossible to cache, due necessary queryString for each different SWF so that classic c.swf will be required for each call



Object Tag Behavior

The Satay method is based over the assumption that an object tag, with a forced type, will help the browser to recognize the SWF.
At the same time, if Flash Player is not present or it has been disabled, Satay trick allows us to provide an alternative content inside the Object itself.
What we should be aware is that Internet Explorer won't execute any script tag inside the object.
At the same time, Internet Explorer and for some reason Opera as well, is the only one able to recognize and correctly execute the SWF without effort at all.
This is why my proposal relies into JavaScript, excluding Opera from the list of browser that should replace the object tag with the embed one.

Removed Data Property

The reason Satay loads two times the SWF, even if this is executed only once, is the data property. Once it is interpreted, Firefox and every other will understand the object itself and the classic "param name movie" will be re-evaluated. On the other hand, if there is a "param name movie" this is the one used by Internet Explorer to understand which movie should be loaded and interpreted via Flash Player plug-in.
Being this node available for every other browser as well, we can use its value to understand the movie replacing the whole object with an embed that will have the same src.

Alternative Content

If the Flash Player is not present/enabled the script won't perform anything except remove itself from the DOM since once executed, it does not need to do anything else. This means that the browser will simply show the alternative content being unable to understand what kind of object has been encountered, so we still have the nice layout fallback.

WebReflection Solution: HTML5 Layout Example


<!DOCTYPE html>
<html>
<head>
<script>
// generic function to initialize the SWF
function ASReady(msg) {
// IE + Others way to access the SWF exposed properties
(window["my-swf"] || document["my-swf"]).hello(msg);
};
</script>
</head>
<body>
<!--// regular object as if it is for IE/Opera only //-->
<object id="my-swf" type="application/x-shockwave-flash" width="43" height="72">
<param name="movie" value="alert.swf" />
<param name="FlashVars" value="msg=<?php echo rand(0, 100000); ?>" />
<!--// optional stuff to show if Flash Player is disabled //-->
<img src="alert.png" width="43" height="72" alt="" />
<!--// the tricky script, interpreted by every browser but IE //-->
<script src="satay2.min.js"></script>
</object>
</body>
</html>

Above layout passed without problems the W3 validator.
Please note that I am not using the classic query string to understand which file should be eventually loaded but a better FlashVars dedicated param node.
In this way the generic c.swf file can be reused without problems even via absolute url inclusion and finally cached directly via browser.

WebReflection Solution: satay2.js


(function (window) {
// (C) WebReflection - Mit Style License

// let's try to be future proof ...
"use strict";
for (var
// just ashortcut
type = "application/x-shockwave-flash",
// plugins property or ...
plugins = navigator.plugins,
// mimeTypes one
mimeTypes = navigator.mimeTypes,
// this operation should be performed only if it's not opera
enabledPlugin = !window.opera &&
// if plugins exists and "Shockwave Flash" is a valid property
(plugins && plugins["Shockwave Flash"]) ||
// or if mimeTypes plus $type exists and enabledPlugin is true
(mimeTypes && mimeTypes[type] && mimeTypes[type].enabledPlugin),
// grab the current script
script = document.getElementsByTagName("script"),
// set the current script as the last one (normal flow)
// find the parentNode (NOTE: quirks only)
object = (script = script[script.length - 1]).parentNode,
// create the element if necessary
embed = enabledPlugin && document.createElement("embed"),
// find out each param node, if necessary
param = enabledPlugin && object.getElementsByTagName("param"),
// set loop range
i = 0, length = enabledPlugin ? param.length : 0;
i < length; ++i
) {
// for each param, set relative embed tag property
embed.setAttribute(param[i].name === "movie" ? "src" : param[i].name, param[i].value);
};
// only if Flash player is present and enabled ...
if (enabledPlugin) {
// for each object attribute, set it into the embed node (id included, if any)
for (var attributes = object.attributes, i = 0, length = attributes.length; i < length; ++i) {
embed.setAttribute(attributes[i].name, attributes[i].value);
};
// replace the object with the embed node
object.parentNode.replaceChild(embed, object);
} else {
// remove this script, nothing to do
script.parentNode.removeChild(script);
};
})(this);

Via few checks and a couple of loops, above script, about 350 bytes minified and gzipped, will replace the object with the only element able to serve SWFs with browsers such: Firefox, Chrome, Safari, and few others.

WebReflection Solution: AS 2.0 Example

Just for this demo I have created an SWF which aim is to tell us if everything is working properly.

// dependencies
import flash.external.ExternalInterface;

// expose a hello callback to JavaScript.
// this callback accepts a string and it will perform a JavaScript alert
// with the text "Hello! " plus the received string.
ExternalInterface.addCallback("hello", this, function (msg:String):Void {
ExternalInterface.call("alert", "Hello! " + msg);
});

// initialize this SWF calling global JavaScript ASReady function.
// this.msg will be the variable set via FlashVars param
// for this demo, simply a random number generated via PHP
ExternalInterface.call("ASReady", this.msg);

// good old stop(); to avoid loops over the current frame
stop();

You can find a live demo in this page monitoring, or not, network traffic to discover that finally the SWF is requested only once rather than twice.
This should even speed up the execution thanks to non blocking embed.src nature and the missed, useless, second request to the server (a 304 that is still an extra pointless request).

As Summary

If we would like to make markup as clear as possible respecting validation and using all we can use to speed up layout execution, the only MUST for this method is a proper non quirk layout.
In any case, this was the purpose of Satay method as well so, if we liked that one, I am sure we can appreciate mine proposal.

Saturday, January 02, 2010

The Solution Is Simple: Buy A Netbook And Test There!

Something every web developer should do, is test whatever Web related stuff into new generation devices such netbooks, low cost notebook, old PCs and/or smart phones.
If a non techie user surfs a website and the latter one horribly slows down his "device", in the most common case, and specially if the website is "famous", this user will blame its wonderful piece of technology, rather than the infamous designer/developer that created the problem.

This happened recently, as example, in Hotamail and with the latest Sherlock Holmes Flash banner.



The Solution Is Simple

Starting with the fact that Junior Flash developers are as responsible as advertisement hosts, unable to filter proper banners from annoying one, if a company would like to provide these heavy computation banners it should simply make a little investment as a whatever Atom CPU based device is (even just an all in one motherboard is enough!).
Even better, it could recycle a generic good old Pentium III based PC in order to be sure that computation is reasonable, where for reasonable I mean no more than 50% as maximum peak.

As an old ActionScript developer, I've always found disturbing the fact people paid to create ads, are too often unaware of problems they could cause.

I have already commented here or elsewhere old Tiscali or IBM heavy banners, recently improved and much less painful for low cost CPUs, I still find ridiculous that in 2010, the beginning of the mobile and low power consumption era, a good movie as Sherlock Holmes is could be sponsored in such obtrusive way: obtrusive for nowadays net dedicated devices: please change it!