Hi gang,
After a year away from Smalltalk I have come back to the light. Still catching up on all the changes... phew quite a task. Still much of the chatter reminds me of my reaction to Les Miserables... "such a lot of fuss over a piece of toast!" ;-}>
On Wednesday, October 16, 2002, at 07:32 AM, goran.hultgren@bluefish.se wrote:
I am not so sure - Ginsu is a model describing Smalltalk source code - separately from the Smalltalk model itself. At least that is my understanding. Modules is instead an extension to the Smalltalk model of classes. Way back when I talked with Henrik about this I found his arguments and model much more appealing than having an "extra" model like Ginsu.
Well, you have missed the key distinction. "Ginsu" was about a declaration of the model of the semantics of a Smalltalk program. A non-reflective description language of a reflective execution environment. The essential distinction is the separation of the declaration from *any* implementation of the semantic model specified. This first distinction is the key to allowing the revision of the state of a Smalltalk program... independent of any particular image or runtime implementation.
The draft of the ANSI Smalltalk standard v1.9 has sidebar comments that go into some detail in this regard. Also, OOPSLA '88 Alan Wirfs-Brock and Brian Wilkerson wrote the seminal paper on Modular Smalltalk which is the mother of the ginsu approach to Smalltalk modularity.
<aside for the interested reader> This subtle distinction is a profound one when considering the evolution of form. (cf G.-Spencer Brown "The Laws of Form") Follow all the injunctions, contemplate the declaration of formal indication, the consequent arithmetic and algebra and finally the introduction of formal self reference in a form that experiences temporal evolution of signal. </aside for the interested reader>
For example - the ability to have classes loaded in the image (fully compiled etc so that tools work and so on) but not having them activated in the name space seemed like a brilliant approach. And activation through big become-operation seemed very neat.
How is that distinct from having tools that operate on declarations of the program with all methods fully compilable and loadable? At Digitalk, Steve Messick did some very cool remote development on headless images. Utilities like "cp" could be as small as a 30k image, with the capability of attaching the program to the declaration giving full debug and development support. (Imagine programs being a kind of project with a completely separate namespace living in a separate runtime process somewhere on the network... all with development ui's switchable the way in which we switch between projects.) That is my definition of neat. OBTW, the development environment itself was just another program...
I talked with Henrik about Ginsu and he said that he had looked at it and thought that similar goals could be achieved better using other techniques. And then he wrote Modules. Since he knows this stuff infinitely better than me (especially compared with Ginsu) I can only hope he posts his thoughts.
Perhaps that is indeed the case. Nevertheless, dig up a copy of VSE if you can. Load Team/V. Open a standard class browser and edit away. Use the disk browser and file in a bunch of module unaware code. All of that stuff winds up in a module called, *Unpackaged*. Most folks never knew that the old fashioned browser was no longer editing the classes and methods themselves, but instead declarations of the aforesaid. I suppose my point is that all of this is based upon many years of experience with making Smalltalk more modular.