| ||
Modularization: Using Several Files |
Fragment groups, forms, and propertiesA source file is called a fragment group, because it contains a number of fragment forms along with the specification of the relation to other fragment groups, the fragment properties:
Fragment graphsWhen we have several fragment groups in a program, we must have a way to specify which groups are included, and what the relations are within this set of fragment groups. This is done by constructing a fragment graph according to the fragment properties of the groups. The starting point is always one distinguished fragment group, the seed of the fragment graph. This is the fragment group which is specified as "the file to execute" when starting gbeta, probably what you think of as the "main file" of the program. Starting from the seed, we construct two graphs whose nodes are fragment groups and whose edges are properties. The following two paragraphs give a precise definition of the concepts of extent and domain, and the third paragraph gives a more understandable explanation (depending on your attitude to math ;-).
The first graph, the extent graph, contains the groups which
are reachable from the seed via some number of
Starting from any fragment group
Another way to explain this is that the extent contains all
the source code you can find by looking into fragment groups mentioned
in properties of the seed group, or of groups looked up that way, or
of groups looked up from there etc.etc. When you have outlined the
extent, you can determine the domain of each group by a
similar, repeated lookup process, but this time you are not allowed to
use the
The basic intuition is that you use a
The
ORIGIN property
tells in what direction the fragment forms in this group must
travel to find their ultimate destination. This intuition reaches
back to the search-and-replace semantics of slots, and when several
groups (files) are involved and the search-and-replace process must
cross group borders, the source code which gets inserted to
replace the <<SLOT ..>> expressions must
travel exclusively along ORIGIN edges in the extent
graph. In other words,
How to handle this?The fact that graphs and lots of transitive closures are at the heart of the definition of the module system of gbeta (and traditional BETA as well) may make it seem counter-intuitive and unmanageable in practice. However, having worked with this system for years (as a student programmer using BETA for many tasks), I find it very intuitive and extremely expressive. Moreover, the fragment system is being taught to second year C.S. students at Århus University every year, so it should be possible to achieve a working knowledge of it in a reasonable time. Looking at concrete examples is surely a good approach.
Expanding a little on the expressiveness: It is trivial, for example,
to set up a visibility-scheme which hides certain aspects of the
implementation of one pattern from its sub-patterns (similar to C++
An important difference is that this scheme is much more fine-grained
than the others. It is e.g. possible to allow one particular
imperative from one particular method of a pattern to depend on (have
access to) some subset of another pattern, possibly a super-pattern.
And, equally important, since interface and implementation can be kept
in different files, patterns depending on the interface of a given
pattern Another important difference is that access is seized by the party which "depends-on," not granted by the party which is being "depended-on." This means that tool support is needed to detect whether "somebody are looking at something they shouldn't see," but on the other hand there is no need to change the code being "depended-on" when some other code wishes to "depend-on" it. The philosophy is that the vulnerable party (which breaks if the other party changes) declares the vulnerability. Finally, we're ready to look at a complete, concrete example in the next section. |