full isolation

[goran.krampe at bluefish.se]

Hi guys!


"Lex Spoon" <lex at cc.gatech.edu> wrote:
> There has been some murmering about full isolation, both pro and
> against.  The idea is that modules will be totally insulated from each
> other and thus unable to cause each other any harm.
[SNIP of rest]

I have been writing an "article" or "brainstorm" or whatever the last
few days, I will make it available soon but need to think it through a
little bit more. Anyway, it roughly describes an approach with these
main points:

- We separate between "loaded" and "activated" modules. This IMHO was a
thing that Modules3.3 got Right. A module should ALWAYS be loadable
(getting it into the image) but when it is only loaded it should just
"be there" for tools to work at. It should not affect anything.

- We use ImageSegments for modules. I have stepped through the
ImageSegment code a bit to refresh my memory and while some of it can
probably be cleaned up I think it is a really nice way to go with
Modules, at least as the primary mechanism - nothing preventing other
means of loading/constructing a Module of course. This would implicitly
define a Module to contain objects - not source code. My sketch simply
means we rip out a bunch of classes/globals in an ImageSegment with some
extra info with it. So they are already compiled etc, just need to "hook
them in". Kinda like a ".dll" for Squeak. :)

- When activating a module it is "hooked up" using various mechanisms.
This is when it will affect the image, and just as Lex says - it can't
be totally isolated per definition. :) And to still hold it with a
single reference when activated would mean making a lot of references
that are pretty fundamental today to be dynamic lookups. I am leaning
again to use something similar to Modules3.3 here - a batch become
operation to hook things up. So an *activated* module would *not* only
be held in a single reference - but a deactivated one or just a loaded
one would. So if the Module/system keeps enough info around it should be
able to deactivate too - thus disconnecting the objects in the Module
from the rest of the image in a controlled way (think superclass,
subclass references yaddayadda).

Well, enough now - I need to finish the writeup. :) And no - this is not
a "proposal" - this is "loud thinking". The writeup includes some
explanations on how things work today - so even if you all guys think I
am hallucinating - it should be nice to read anyway.

regards, Göran