Provides ACE handling and class loading algorithms, including the (in)famous "distance class loader". Let's explain how this algorithm works.

Classes are stored in clusters which are physical directories. Those clusters are organized:

• either explicitly via an ACE file,
• or implicitly via configuration files.

In both cases, clusters are organized in a tree. The interface of this tree is CLASSES. The root instance of the tree is a direct instance of UNIVERSE, which is a singleton. Node instances of the tree are direct instances of LOADPATH. Leaf instances, i.e. the ones holding a reference to an actual cluster, are direct instances of CLASSES_TREE. Note that both inherit from CLUSTERS, and technically a CLASSES_TREE is a node that may contain other cluster nodes. In fact that's not the case but that could change of course ;-)

How do we load classes now that the tree is built?

A class is searched starting from who searches it. A "provider" class is always looked for in conjunction to its "client". We compute the distance between the client and one or more would-be provider classes having the same name, and the closest class is selected.

The distance is calculated thus:

• The class loader tries to look for the provider class in the same cluster as the client class' and below (in the clusters tree). If it find one or more below, it will select the closest in priority and stop its lookup.
• Otherwise, it tries again starting from the parent of the client class' cluster... Until reaching the Universe. If at that stage no class is found, no class is returned (usually leading to a "class not found" error...)

This cluster contains all the main classes used to implement the SmartEiffel tools.

Provides all types of EXPRESSIONs.

Provides all types of E_FEATUREs.

Provides all types of INSTRUCTIONs.

Maybe one of the most important clusters. This cluster contains all the classes one should first get used to in order to understand how the compiler and the other tools work. Those classes contain the core algorithms and structures used by the SmartEiffel suite.

Provides all types of RUN_FEATUREs.

Provides for all kinds of Eiffel types of entities. For example, MY_OBJECT and like my_object type markers lead to different TYPE_MARKs. Among the most frequent are:

• ANCHORED_TYPE_MARK is used for entities declared as like something.
• KERNEL_EXPANDED_TYPE_MARK is used for "basic expanded" Eiffel types (integers, characters and so on).
• CLASS_NAME_TYPE_MARK which marks a type directly derived from a class.
• USER_GENERIC_TYPE_MARK handles types instanciated from generic classes (except arrays, managed by ARRAY_TYPE_MARK and NATIVE_ARRAY_TYPE_MARK)

Provides the Acyclic Visitor Design Pattern.

Most data classes are visitable; but a lot are not, when it has no sense to make them so. In this category go all the algorithm classes (tools/kernel cluster), pools, singletons, and framework classes (such as GLOBALS).