> It seems to me this would do a great job of storing unneeded  
classes (they are
> mono-rooted trees) and projects or morphic worlds, or books.
....
>  The third would write the binary patch to a file, leaving only  
the file
> reference and outpointers behind.  The third form works a lot like  
a DLL.

Hi Dan,

I am really happy to see you tackling modularity.  What I would like  
to see is a way for putting frequently used but mostly static stuff  
into Squeak shared libraries as well.  These would have to be  
explicitly loaded at startup, in order to avoid the problems with  
direct VM references you pointed out for the auto-faulting scheme.

For each class in such a shared library / package, an  
'external-class' class-object is created within the importing image  
pointing to the CompiledMethods etc. stored externally.  When the  
importing image is saved, these external class proxies simply save  
their package-reference.  The 'system' pointer approach for accessing  
globals should help avoid out-pointers.

The external class proxies could even support modifications that are  
reflected only within the image but leave the imported package alone  
+ the generation of a new package with those changes applied ('flush  
changes to new package').

Somethng like this would help Squeak support light-weight scripting  
tasks and the model of many different images, instead of a single  
mega-image with stuff swapped in and out.

Marcel