While I liked Christian's comments about packages, I was not quite as
enthusiastic about this one, at least not in the sense that he proposed.

Mainly, I think it is unneccessary for the case he cites- finding classes
in differing modules.  Here's my proposal, which may or may not be better:

Instead of relying upon hierarchical naming schemes, instead rely upon
objects within the image which are responsible for resolving variable
requests.  In this scheme:

	Module components define variables, but some such as classes
	and their methods require that variables be resolved ( such
	as references to a superclass, other classes, other globals,
	as found within the methods of a given class ).

	Modules resolve variables within their scope, but keep track
	of the variables they could not resolve.  These are the modules'
	Required Variables.  They may or may not be essential, but
	something somewhere within the module thinks it needs them.
	
	In order to maintain their independence, the modules are ignorant
	of the world beyond their boundaries. It is up to some other objects
	to bind them together to form the code base for a System.  For
	lack of a better name, lets call them Backplanes.  Modules know
	what variables they need, but they also know what they provide.
	Backplanes can resolve these provisions and needs across several
	modules.  In a sense, instantiated modules are plugged into backplanes,
	and backplanes are plugged into other backplanes or, ultimately, into
	the System representing the code base of a particular World within
	your image.

	Worlds exist within a given image- some worlds might represent other
	Smalltalk dialects, such as Squeak, Gnu Smalltalk, Little Smalltalk,
	V/DOS, V/286, V/Win, VisualWorks, whatever, living in the same image.
	The worlds might represent different versions of these various dialects.
	
Although there is hierarchy, it is never referenced anywhere within the code.
Nothing is sought based on a presumedly pre-existing structure which must
be in place for all time.  Backplanes can be reconfigured at will, with no
changes to any source code.  There is no difference between code written
without modules, and code written with modules.  The compiler is unchanged,
aside from any improvements that could be done with or without worrying about
modules.

I've been working on this scheme intermittently for quite a while, but unfortunately
do not have it in a state to release, and do not at this stage know if there
are other caveats that could sink it.

les