Errata

in the new version of findNodes code:
var findNodes = function (callback, callback_obj) {
if ( typeof callback === "string" ) {
callback = calbback_obj[callback];
}

the callback parameter passed is a string, and there is something behind the sense is it gets the method of object using its string. I think it worth to mention it.

I lost at this point after some searching for the using [] to get the method.

In my version of this (e-)book, the author wrote:

"If you call findNodes(myapp.paint), it won?t work as expected, because this.color will not be defined. The object this will refer to the global object because findNodes() is invoked as a function, not as a method. If findNodes() was defined as a method of an object called dom (like dom.findNodes()), then this inside of the callback would refer to dom instead of the expected myapp."

In my opinion, the argumentation is misleading. If findeNotes() is invoked as a method or invoked as a function is irrelevant for the this-value in the method myapp.paint() . In either case the this-value will be refer to the global object, because it is determined by the form of the invocation "callback(found)" (See http://dmitrysoshnikov.com/ecmascript/javascript-the-core/#this-value).

This is not really an errata, but a suggestion for a new pattern, combining self-defining functions and init-time branching.

In stead of initialising the add- and removeListener() methods init-time, you could use the self-defining pattern to define those functions the first time they are called.
This way, they'd only be initialised when they're actually used, which is even more efficient than init-time branching.

Maybe the pattern should be called lazy initialisation?

The example itself looks like this:

var alien = {
sayHi: function (who) {
return "Hello" + (who ? ", " + who : "") + "!";
};
}

alien.sayHi('world'); // "Hello, world!"
sayHi.apply(alien, ["humans"]); // "Hello, humans!"

One problem that I have with this is that the sayHi function shouldn't exist given the code directly preceding the example. I suppose you were referring to the earlier sayHi function separated by a lot. Not a big deal.

What was a little bit more confusing was that it is a little bit unclear in what you demonstrating. Are you saying that these two examples (other than the argument) are essentially identical? Will "this" be the same inside of them? I think that's what you mean by "When a function is a method of an object, there?s no null reference passed around (as in the previous example). Here the object becomes the first argument to apply()", but it might be a little more helpful if the examples used "this" in some way to demonstrate how the different applies work.

A minor complaint in an otherwise flawless book!

One other thing. Earlier in the page speaking about how to use apply you wrote, "the second is an array or arguments"

I believe it should say:
the second is an array of arguments

Hope these few suggestions help!

"Often developers use the convention of making the global variable APP CAPS, so it stands out to the readers of the code."

This is true for YAHOO/YUI, but I don't think this is "often" the case. Take a look at the list of registry candidates on openajax.org:

http://www.openajax.org/member/wiki/Registry_Candidates

Empirically, it is not common for library prefixes to be all caps.

"namespace" is allegedly a "potentially future reserved word" in JavaScript:

http://javascript.about.com/library/blreserved.htm

so it's probably not a good idea to recommend it as a property name, such as MYAPP.namespace.

Is the prefix necessary? Shouldn't the use of hasOwnProperty take care of collisions with things like 'toString'?

I'm not sure if this is a great example of chaining:

document.getElementsByTagName('head')[0].appendChild(newnode);

Getter methods, like getElementsByTagName(), are expected to return a value, so there is nothing unique about chaining such methods. Mutator methods, such as appendChild(), are not always expected to, which is what I think you're trying to get at when talking about chaining.

Your obj.increment().add(3).shout() is a good example of this because those are three mutator methods put together. The DOM example doesn't seem as illustrative.

In this Holy Grail example, shouldn't the Child still call Parent's constructor method:

function Child() {
Parent.apply(this.arguments);
}
inherit(Child, Parent);

This is at least how things are done in the Closure Library.

The beginning of this expression:

if (Child.uber

can Child.uber ever be false in a boolean context? It seems like it should not be possible because of how it is defined:

Child.uber = Parent.prototype

I suppose you would have to do something pretty strange like:

var obj = {};
obj.__proto__ = null;

klass(obj, props);

maybe?

Although "inheritance" at more than one level is not explicitly discussed in this section, it seems that it is not correctly managed by the klass function.

Let's say we defined another "class" like so:

var UltraMan = klass(SuperMan, {
__construct: function (what) {
console.log("UltraMan's constructor");
},
getName: function () {
var say = UltraMan.uber.getName.call(this);
return "Tada! " + say;
}
});

and we defined the following object,
var ul = new UltraMan('Urutoraman');
we can notice that Man's constructor is not called.

This is apparently because the __construct property is not recursively called for the ancestral "classes". It is just called for the immediate Parent.

A quick and dirty fix would be to change the definition of Child (inside the klass function) like so:

Child = function () {
// Don't call ctor if Parent is Object! (tail condition)
if (Child.uber !== Object.prototype) {
Child.uber.constructor.apply(this, arguments);
}

if (Child.prototype.hasOwnProperty("__construct")) {
Child.prototype.__construct.apply(this, arguments);
}
};

The tail condition of the recursion is managed when we reach the Object constructor, which does not have any "__construct" property.

I'm not sure this is a valid example of the decorator pattern because in some examples, the contract of getPrice() is that it returns a string, and in other cases, it returns a number. I thought that a decorator should maintain the original API and that it should be transparent to the user. In this case, because of the changes in the API, the order in which the decorators are applied are particularly important, so there is no such transparency.