full isolation

[Alexandre Bergel]

I have been away these last days, that's why I was pretty silent...
Would it be possible to set up this list in such a way that when one answers, the answer is sent to the list rather than privately.

> 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.

One serious issue concern meta programming. I believe that achieving a descent isolation mechanism require a complete overhaul of the reflective facility. It seems that the Self mirror mechanism would provide an interesting solution...


> 	1. Every module must have its own thread.  Otherwise,

Why ? Classboxes do not impose such a constraint.

> 	2. Modules must interact by passing messages or events, and not by
> simple call and return.  Otherwise, when you call, the other module can
> simply choose not to ever respond.

???
Can you provide a concrete example ?

> 	3. Classes need to be modified.  In particular, you can't let people
> send #class to get a real class object, and then use #superclass and
> #subclasses to browse around the class hierarchy.  You also probably
> don't want modules calling #compiledMethodAt:put:.

yep, metaprogramming and reflective features should be reshaped...

> Instead, focus on trying to prevent common accidents, and to allow common
> desired interactions.  Two modules accidentally defining a "Server" class is
> a common kind of accident, as are two modules trying to add a ">>" method to
> class Behavior.  What should happen, in such a situation?

Look at the Selector Namespace and Classboxes...

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.