[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.
squeak-dev@lists.squeakfoundation.org