Generalized Object Modules Design
Anthony Hannan
ajh18 at cornell.edu
Sat Mar 2 02:44:51 UTC 2002
Alright, my design has evolved already, here is version 2.
Modules are organized in a multiple inheritance hierarchy. Each module
provides a name space that contains the names of its local objects
plus the local names in all inherited modules. Names are searched in
topological sort order, ambiguous names raise an error (This search is
only required during compilation).
Instead of a module being a repository for objects it is just another
object like a class whose main purpose is to provide a name space as
described above. Objects will instead be stored in image segments (see
below).
Methods are compiled with respect to the current working module.
Selectors and globals are looked up in the modules name space.
Ambiguities are presented to the user allowing him to choose a specific
inheritance path to disambiguate. Selectors, like globals, are named
objects of modules. Instead of storing selectors in a global symbol table,
they are stored in modules. The same selector name in two different modules
will be treated as different selectors, compiling will bind the method header
and message sends to one or the other.
Code can reference a named object that is not inherited by supplying the
module path from an inherited module down to the name object. When a
name is added or deleted, all methods that use that name are rebound in
case they are affected.
The current database transaction notes all loads and changes to the
image. Upon commit all changes are submitted to the active database. The
database will accept the commit if it does not conflict with other concurrent
changes. Multiple pending transactions and nested transactions could also be
implemented.
The main database should contain all "approved" Squeak segments. It
can be forked to allow different variants (like 'stable', 'alpha', and
'personal' for each user). Transactions are not forgotten when commited,
they are kept around as database layers. A layer can be copied and applied
to another database if it does not introduce inconsistencies. And a layer can
be broken apart or merged into another layer. A layer would be equivalent
to today's changesets.
An image segment is the same as today's image segment, it contains all
objects reachables from a set of roots that are not reachable from
anywhere else. Pointers to objects outside the segment (outPointers)
are converted to stubs when its segment or the target segment is
unloaded. These stubs reference root objects in other segments by
segment id and root number. So records of the Squeak database would be
image segments with unique ids and foreign keys that reference other
segments.
Squeak would organize objects into segments automatically. One scheme
is put each module in a different segment, then objects that are
reachable from more that one module would be added as a root to the
segment whose module is the closest pointer to it.
I like this design better from my first one because it separates name
space functionality from database functionality.
Cheers,
Anthony
More information about the Squeak-dev
mailing list
|