Modularizing (Was: How to setup squeak as an NT service)
Boris G. Chr. Shingarov
usib6tfj at pol.ru
Sun Mar 22 03:56:06 UTC 1998
> the Squeak's window creation must be done in the upper level
> (in Smalltalk) and not by the VM !
Absolutely. Cheese (all versions) does it that way.
> I think that we must try to fractionate the image,
> and support dynamically bound subspaces of objects.
> It will help to produce native OS wrappers and
> other loadable-on-demand frameworks.
This is what I dreamed for from day 1 of Cheese.
In Cheese 5, the design is such that *the image*, not only
*the source code*, is completely platform-indepenent.
That is, imagine a scenario like this: a Squeaker starts
his image on his NT box and sees a native NT Transcript.
>From Transcript's menu, he opens a browser where he creates
a subclass of Window with instance variables 'text' and
'saveButton', and implements the following instance methods:
saveButton _ PushButton named: 'Save'.
saveButton topAttachment: #self; topOffset: 30.
saveButton whenClickedSend: #save to: self.
text _ MLE new.
text bottomAttachment: #pane pane: saveButton.
self addPane: saveButton; addPane: text.
| string |
string _ text text.
... code to save string into file ...
(The code shown does actually work with my current
image, but only on OS/2 PM).
Then, our fellow saves his image and transfers it to
an OS/2 (PM) or Unix (Motif/Lesstif) machine. The only
thing he should care about is to correctly transfer the
file. Then he starts the image, does 'MyEditor new open',
and enjoys the new look and feel. But that's not all:
one can save the image with a MyEditor being open,
transfer to another OS, and see the window upon startup.
Cheese 5 achieves this by using proxies for all its classes.
Class Window implements doesNotUnderstand: which forwards
all messages to the actual object which was created in
Window class>>new. The latter obtains which l&f flavour
from the VM and prefixes the name of the class.
So there are platform-neutral Cheese classes like ListBox,
PushButton, MLE and so on, and parallel <Platform>ListBox,
<Platform>PushButton etc. classes, like PmListBox, WinListBox,
and so on. In an image configured for PM and Motif, the are
ListBox, PmListBox, and MotifListBox classes, all in one
image, and code in Window decides which one to use at any
given moment. To port to another platform, you don't need
to modify any existing code, just add WinListbox or MacListBox
and other classes (and classes that support their fuctionality,
like classes in SqApi for Win*).
And here is where I want to modularize the image. Why should
I have to load Win*, Mac*, and Pm* if I live under Motif?
But on the other hand, I want to share my work with you who
are on Win. If we had a mechanism to split the image into
load-on-demand modules, the problem would go away because
then I'll just have a Motif module on my machine and you'll
have a Win one on yours.
So I definitely see modular images as really necessary, but
I still don't know how to implement them. If anyone has any
> If we "modularize" the VM to have the opportunity to load
> its parts when the "upper (image) objects" need it,
> the complete building of the VM can be done dynamically.
> In commercial versions of Smalltalk like PPD, the user
> have the possibility to write some primitives in an external
> module (e.g. DLL) and bind/unbind a service to a primitive
> number to expand or patch VM behavior.
I was already looking into that. Neat idea. But why make
Squeak do all the work where we can put it on the OS? Just
put different sets of primitives in different DLLs. My own
vision for VM modularity came from the UPs. I had Ian's
sqUserPrimitives.c with his sample primitives, and my own
one with DLL callout (like your SqApi, but for OS/2). 'Ok',
- I said, - 'now I want both, should I produce a merged
sqUserPrimitives.c by hand???' Didn't look like an option...
now it searches for all DLL in the cwd to see if there are
some user primitives to load.
More information about the Squeak-dev