Dan Ingalls wrote:
> Yes, 'twas I.  Here's what I liked and still do like about it:  it is a message-based
> interface to independent modules.  I learned a lot from dealing with the direct
> links in the superclass chain and global variables, when trying to get the full
> advantage out of imageSegment-based modules.

You get very similar advantages when you consider all references to 
"outside" globals be really definitions inside the module's namespace 
itself. In other words, if module Foo would use "Array new" it would 
really mean "Foo::Array" (e.g., the value of #Array inside the module 
Foo) and you could populate (parametrize) that via, say "Foo::Array := 
Collections::Array" etc. This has the added advantage that there is no 
true "global" access to anything (e.g., no ambient authority beyound 
what was explicitly given to the module) and that multiple modules can 
co-exist with different parametrizations.

> Let me call your attention to a couple of "pros" that I consider to be
> quite compelling...
> 
> 1.  With this architecture it is not only possible, but trivially simple
> and atomically fast  to execute, eg,
> 	OldFiles := Files.  Files := FlowVers2.
> One bytecode, and every access to the File module now
> goes to the new package under test.  Obviously if something
> goes wrong, order is restored with
> 	Files := OldFiles.
> 
> 2.  I have always felt that if things are structured right, then "uninstall"
> is already provided by the garbage collector.  When you are ready to
> get rid of the old file system, then
> 	Files := FlowVers2.
> does the job clean and fast because none of the global references
> are direct.
> 
> Both of these are valuable, and they're not simple in many
> competing architectures.  Or to put it another way, competitors
> should be evaluated with these desiderata in mind.

Unless I misunderstand, both would be utterly trivial in the above. 
Since all references are defined in the module's namespace you can do 1) 
trivially for any module you'd like and 2) falls out naturally too 
(unless I'm missing some subtlety).

> Just as we hope with Spoon, or any other modular build scheme,
> to build up a system from a clean load of packages, if the modules
> behave right, you should be able *equally simply* to get back
> to the kernel by discard methods that do little else than store nil.

Right.

> Finally, part of my motivation in all this was to establish criteria
> that would allow the modules to be stored as image segments
> so that the load process could be blindingly fast.  For example,
> back when the VM-Construction category was a quarter megabyte
> it loaded in less than 100 milliseconds done this way.

Right.

> I think much was right about Environmnents, but
> i think I agree with a criticism Mike Rueger once voiced that the modules
> should be as simple as possible, and that building in a hierarchy is
> probably not the right thing to do.

Right. In particular name lookup gets messy, even today, if defined in 
multiple places (pools, class vars, environment...) - and that is 
another reason why I like the :: syntax. One could require that 
references to class or pool vars always need to be prefixed so that it's 
clear to the user that PrimitiveVertexSize is not defined in Smalltalk 
but rather via B3DEngineConstants::PrimitiveVertexSize.

Cheers,
   - Andreas