This article is for the theoretically inclined among us :-).

When putting together a JavaScript application order matters. Since the browser
evaluates JavaScript code in the order it arrives, every code that is referenced
by other code has to come beforehand, in order for that reference to succeed.
This for example affects calls to other functions within the body of a certain
function, since these references are resolved at load time by the interpreter.

The same holds true for the prototype reference used for a "derived" class
(constructor) object. The "ancestor" function has to be loaded before you can
use it as the prototype for another function.

In qooxdoo, classes are declared as maps which are passed to a
class-constructing method, qx.Class.define(). This method creates the basic constructor object, sets the prototype and other prototype properties, and so forth. It is only when qx.Class.define is actually executed that all referenced objects in the class definition have to be in place, the most prominent being the "extend" member of the class which names its parent class.

qooxdoo's generator goes to some length to assure that classes are constructed in the right order. This is reflected in the script/<application>.js file which contains a list to the appropriate class files (in the "source" version), or the actual class code (in the "build" version). Obviously, classes that serve as base classes for others have to come earlier. But this is not all there is to it. Classes not only inherit from other classes, they also use them, through creating instances of them in their own code or calling out to static functions. Whenever code that does that is evaluated those other classes have to be in place.

You probably already know where this is going to, there is a risk of circular dependencies. A simple example might illustrate that. Most classes in qooxdoo derive from qx.core.Object, e.g. the Logger class. But qx.core.Object itself might want to start logging early when it is created, that is "use" a Logger instance. Another typical example for complications of this kind is the 'tr' function that needs a qx.locale.LocalizedString, which might not be present at the time you call 'tr'. A point in the class declaration where this might crop up is the 'defer' section, which contains code that is actually run after the class has been constructed, but might include references to classes that are not readily present in the interpreter.

On a general level what we are looking for is a partial order on the set of qooxdoo classes, the relations in question being "require" (the other class is a parent class) and "use" (the other class is used in the code). The question is: Is there a partial order for the qooxdoo classes under the combined relation "require/use" where a class A "comes before" a class B exactly when A is required by B and/or A is used by B. Only if there is such an order can qooxdoo classes be sequenced consistently.