Dave <dave at bedarra.com> is widely believed to have written:

> 
> 
> 1. The mechanism for unloading is indeed a good deal more complex than
> loading and was one of the throny problems OTI had to address in
> building embedded Smalltalk and Java. 
> 
> Perhaps the issue of unloading is something to be deferred until after
> the basic module and component mechanisms are defined and tested?
I was just thinking something similar; that maybe _un_loading isn't
really all that interesting. Here's why -
the typical application distribution job is to assemble one's code along
with enough support code to run properly. As long as we have a system
that we can put together easily, and that has tools/capabilities to
allows us to be sure that any particular app is 'clean', then we ought
to be safe in assuming that assembling a 'user' system from the
appropriate base components plus our own app code will produce a
workable program. In most cases I rather suspect that this would be
equivalent to something like
base + gui + programming tools + myApp works
therefore
base + gui + myApp will work
I'm not at all sure I've written this terribly well, but you can
probably see what I'm getting at.

tim  - no longer on fire :-) 
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
"!sgub evah t'nseod CP sihT ?sgub naem ayaddahW"