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:
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:
This cluster contains all the main classes used to implement the SmartEiffel tools.
Provides all types of EXPRESSION
s.
Provides all types of INSTRUCTION
s.
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_FEATURE
s.
Provides for all kinds of Eiffel types of entities. For
example, MY_OBJECT
and like my_object
type
markers lead to different TYPE_MARK
s. 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
).
This cluster provides deferred classes that abstract out component behaviour:
CODE
is the interfave of thetools/code
component. It represents a code element (either an expression or an instruction). Note that each code is either an instruction or an expression (see below). The classes in thetools/code
component are intended to be inserted rather than inherited (they add specific behaviour to some instructions and expressions).EXPRESSION
is the interface of thetools/expression
component. It represents an Eiffel expression, i.e. a syntactic construction having a result type.INSTRUCTION
is the interface of thetools/instruction
component. It represents an Eiffel instruction.PARSER
is the interface of thetools/parser
component. It parses a file (an Eiffel file, an ACE file or a configuration file) and extracts syntactic information.RUN_FEATURE
is the interface of thetools/run_feature
component. It represents a live feature, i.e. a callable feature tailored for some particularLIVE_TYPE
.TYPE_MARK
is the interface of thetools/type_mark
component. It represents an Eiffel type.Moreover, the class
SMART_EIFFEL
drives the compilation process. It stays in this cluster because it is so important.