Anthony,

> I agree World is dynamic, especially in a multi-user system.  
> But I would use the execution stack as the dynamic scope, not 
> a sandbox/island.  World would be obtained by raising a 
> signal.  Some context up the sender chain would respond to it 
> and return it.  This implies that some object that initiated 
> the thread knows which World to act on, which seems 
> appropriate for user actions and even the World stepping loop 
> which would have an instance variable pointing to the actual 
> active World.
> 
> So I think both static scope (pools) and dynamic scope 
> (contexts) are appropriate.  The significance is dynamic 
> scope is not an extra concept like islands.  I believe this 
> is more in line with the objects-as-capabilities concept.

Have you looked at RuntimeEnvironments (on SqueakMap)?  They accomplish
the same effect, but they are cleaner than using exceptions...they also
work when a process is forked.  To do what you describe would look like:

----
Env clamp: [
	Env at: #world put: aWorld.
	self doSomethingThatRequiresAWorld.
].
----
SomeClass>>doSomethingThatRequiresAWorld

	(Env at: #world) doSomething.
----

A Morphic package could also extend the runtime environment accessor to
include #world and #world: methods to make the above even cleaner
looking.

- Stephen