On Fri, 1 Feb 2002, David Simmons wrote:

> Hi All,
> 
> Is it too late to have a hearty discussion here on the squeak discussion
> group regarding namespaces and modules?
> 
> I.e., have the plans for squeak been cast in stone. I've briefly read
> some of the module and namespace discussions on the Wiki.
> 
> If not then I would like to try and participate in a discussion on this
> area with the goal being to strive for some level of compatibility with
> existing Smalltalk implementations of namespaces, modules, etc such as
> in the work I've done for SmallScript (AOS and .NET versions), and its
> ancestor SmalltalkAgents (QKS Smalltalk).
> 
> I would add that this is area where simplicity is truly elegance in the
> best sense of Smalltalk's philosophy. But it is equally an area where
> recognizing synergies and making the right steps for achieving
> simplicity can be a hard thing to get right.
> 
> -- Dave S. [SmallScript LLC]
> 
> SmallScript for the AOS & .NET Platforms
> David.Simmons at SmallScript.com | http://www.smallscript.org

[snip]
 
> > On Thu, 31 Jan 2002, Henrik Gedenryd wrote:
> > 
> > > There are now multiple name spaces, one per module.

> > 
> > I copied this important information on a new swiki page with the title
> > 'Name spaces':
> > 
> > http://minnow.cc.gatech.edu/squeak/2221> 

I suppose that this might be a temporarily issue. The basic challenge
which is now faced is how to refactor the image enough so that some large
chunks can be put into modules.

At the moment the VM construction subsystem and the 3D system are the
first candidates for loading/unloading as a module.

Stephan Ducasse and Ned Konz are doing some refactoring regarding the
FileList as this is a class which has too many hard wired references
from other classes. In this directions many things are underway. 

I was surprised as well to learn that one module corresponds to one name
space. 
But at the moment I feel at ease with it because the challenge is to chop
out some five to seven large chunks of the image as modules living around
a core system and still have a running system. In a sense I don't mind
that a module lives in it's own name space.

There is also a to do list by Dan Ingalls on 
http://minnow.cc.gatech.edu/squeak/2066
(Modules: What to do next)

Cheers
Hannes Hirzel