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