Reactive Squeak ( [VM] Hooks from module into platform support code?)
Marcel Weiher
marcel at metaobject.com
Wed Nov 8 22:35:59 UTC 2000
[Henrik had asked why it wasn't possible to call a Squeak method
from the outside]
[Andreas gave lots of good, technical reasons[
Although the reasons Andreas gives are all excellent, I don't really
think they answer Henrik's question, which I would restate as
follows: why are there all these (absurdly) difficult obstacles to a
rather straightforward requirement. After all, what more basic
requirement can you have for a method than invoking it?
The answer, as so often, is architectural mismatch (*). Squeak is
built around architectural assumptions that make it difficult for it
to interoperate with other systems. One of these assumptions, and
one talked about at length in the referenced paper, is ownership of
the event-loop, of the thread of control.
A system that assumes it has control of the event loop will be
difficult to impossible to integrate with other systems that make the
same assumptions. On the other hand, a stand-alone system must take
charge of the event loop, and Squeak does, in essence, play the part
of a stand-alone system, with the integration problems that we keep
running into.
However, I believe it should not be too difficult, and quite useful,
to re-cast Squeak as a reactive system, similar to the way Objects
were turned into re-active entities in Smalltalk-76 [I hope this
characterization is correct]. One of the keys to this is that
object-oriented systems, unlike procedural ones, don't really need to
be active in order to offer well differentiated reaction to external
stimuli. After all, the basic dispatch-mechanism used in OO is
equivalent to a top-level "receive, dispatch" loop.
A recasting of Squeak would essentially turn it into an object,
replacing the top-level byte-code-based interpret() loop with an
interpreter function that takes an object and a message as an
argument, sends that message to the object and returns. This would
allow Squeak to be integrated much more cleanly into modern operating
systems that provide event-loops for their applications. Current
stand-alone behavior can be trivially regained by a single top-level
loop that repeatedly calls this function.
I also notice more and more ad-hoc OO-style dispatch tables in the
VM-support code. When are we going to bite the bullet and use real
OO for that?
Marcel
(*) "Architectural Mismatch, or, Why it's hard to build systems out
of existing parts", David Garlan, Robert Allen, and John Ockerbloom,
Proceedings of the 17th International Conference on Software
Engineering, April 1995.
More information about the Squeak-dev
mailing list
|