Spoon progress 23 May 2006: finding dependencies via passive imprinting

Hi--

        Recently I made a module for installing ClassBuilder. (Conveniently,
Spoon doesn't need ClassBuilder to install new classes, only to change
old ones.) My first test was to add an instance variable to a class in a
minimal remote memory. The newly-installed remote ClassBuilder itself
behaved fine, but there were a few methods in the remote test class that
needed to be recompiled. The minimal memory has no compiler, so that had
to be swapped in from the control memory (which also has the GUI and
tools I use to run the tests).

        Installing classes and methods into a minimal remote memory, inline as
they are needed, is what I call "passive imprinting". "Active
imprinting" is installing behavior in a minimal remote memory as a
side-effect of running it locally where it already exists. I suggested
in a previous report that only active imprinting is accurate, because a
memory requesting methods for itself has no was to know if a method it
can already run successfully actually has an override.

        The situation seems to have changed with the advent of the "method
placeholders" I mentioned previously[1]. There are already placeholders
in the current minimal memory for each method that hasn't been run since
a certain point in time (the beginning of the most recent shrink), but
whose class is still referred to by something (classes which have no
references are simply removed entirely). As long as placeholders are
installed for each overriden method when a new class is defined, passive
imprinting now works with full accuracy.

        Anyway, since the minimal memory also has no source code at the moment,
the method recompilation involved in my ClassBuilder test also needed
the decompiler. I have the control memory set to mention the classes and
methods it installs on the transcript. During the automatic installation
of the decompiler, I noticed that DialogStream was getting installed,
and, in turn, so was TextStream, Text, Form, Bitmap...

        These were things that didn't seem absolutely necessary for
decompilation. I simply halted the test, noted the point at which
unwanted dependencies were being invoked (MethodNode>>decompileString,
which had also just been installed), and changed the offending method so
that it didn't invoke the first unwanted prerequisite (DialogStream).

        This seems like a great way to find the dependencies between subsystems
in Squeak!

        The advantage that this technique has over one using active imprinting
is speed. With active imprinting, one must probe the remote target
memory after every single local message-send, whereas in the passive
case the target memory just runs methods without pause until it comes to
a placeholder.

        A workflow for finding dependencies and using them to inform module
creation is beginning to appear. It seems we mostly need to come up with
a bunch of desired test cases, and the time to run them and watch for
undesired relationships.

        And this whole project is starting to feel like a PhD I should be
pursuing somewhere. :)


-C

[1]

http://lists.squeakfoundation.org/pipermail/spoon/2006-April/000107.html

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Hello Craig,


CL> A workflow for finding dependencies and using them to inform module
CL> creation is beginning to appear. It seems we mostly need to come up with
CL> a bunch of desired test cases, and the time to run them and watch for
CL> undesired relationships.
this is simply great!

Thank you for your work!




Herbert                            mailto:[hidden email]

On 5/23/06, Craig Latta <[hidden email]> wrote:
>        A workflow for finding dependencies and using them to inform module
> creation is beginning to appear. It seems we mostly need to come up with
> a bunch of desired test cases, and the time to run them and watch for
> undesired relationships.

Let me see if I understand this.  You will put a test case on the
minimal image.  When the minimal image runs, it will sometimes run a
missing method, which will cause the method to be pulled in from the
full image.  Pulling in a method might cause a class to be pulled in,
as well.  The full image will keep a record of what got pulled into
the minimal image, so you can tell exactly what methods the test uses
that is not already part of the minimal image.

Is that right?

-Ralph

Hi Ralph--

 > Let me see if I understand this.  You will put a test case on the
 > minimal image.  When the minimal image runs, it will sometimes run a
 > missing method, which will cause the method to be pulled in from the
 > full image.  Pulling in a method might cause a class to be pulled in,
 > as well.  The full image will keep a record of what got pulled into
 > the minimal image, so you can tell exactly what methods the test uses
 > that is not already part of the minimal image.
 >
 > Is that right?

        Almost; the test case is started from the full image by sending a
message to the appropriate remote object in the minimal image, and the
minimal image records the transfers with a module (somewhat in the
manner of a changeset).

        Module objects from different images know how to synchronize their
respective systems by comparing their contents, so, for example, when a
test case is finished, a minimal image could immediately transfer that
new behavior to another minimal image (which uses another new, empty
module).


        thanks,

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Is the module system new?  I didn't see anything in the December
version of Spoon like that.  Maybe I just don't recognize it.

It is a very good idea.  A module is defined as all the code that is
needed to run a test suite.  To have a module, you must have tests.  I
like it!

-Ralph

Very helpful for understanding the squeak jungle, however we cannot stop here
and say, OK, we have resolved our modularity problems.

Modularity problems come when we start having different versions for the same
class>>method, and this is unavoidable in a living system.

Either two different applications i want both in my image have such a clash
directly, or they will require a third utility of different version...

Mathematically, we could write the problem as:
- we have a set of TestCase we would like to fulfil (good idea)
- we have the set of class>>method ever written in Squeak
- each class>>method has a set of versions, class>>method#n
- only a single version can exist in the image
- which partition of class_i>>method_j#n_k will light all our TestCase to
green ?

Let us imagine we have an enhanced version of Spoon to solve this problem.
When pulling methods in, inheritance must be taken into account, removed
methods are as important as added methods:
if we have a class hierarchy A > B > C, all implementing versions of method m,
and a TestCase doing (C new m), we will have to check all partitions of set
(A>>m,B>>m,C>>m). Each partition being divided into all combinations of
versions m#i...

Too much combinatorial, i think... It could be feasible only if we group
methods in indivisible units (packages...) in order to reduce problem
complexity.

And, this is a rather static view. Our modules may also trap the MNU and
process the case normally (hence we cannot eliminate the empty partition in
above case). Our modules may also well generate classes and methods
dynamically, like already possible in a true dynamic environment like
Squeak...

And last, this is also an ideal case, most applications simply do not have
such a TestCase collection covering 100% of their capabilities. Yes, they
should, but how do you write GUI test like when i push this button, a window
open with contents equal to...?

I did not speak of global variables (class variables mostly), which also cary
a state that can make our TestCase either succeed or fail...

Spoon is promising, but won't solve everything

Nicolas

Le Mardi 23 Mai 2006 20:50, Ralph Johnson a écrit :

Hi Ralph--

 > Is the module system new?  I didn't see anything in the December
 > version of Spoon like that.  Maybe I just don't recognize it.

        The beginnings of it are there. The classes to look at are Module,
Author, MethodDescription, and the others in the 'Spoon-Modules*'
categories. You can browse them in either the control or working
memories. The main difference between that and the latest unreleased
stuff is the way new classes are defined (it no longer uses ClassBuilder).

        Of course, I should just be able to cite the UUID of a module that
refers to everything you should look at, but we're still bootstrapping. :)

 > It is a very good idea.  A module is defined as all the code that is
 > needed to run a test suite.  To have a module, you must have tests.  I
 > like it!

        Cool! I expect that there will be some fiddling with that delineation
(to deal with conceptual overlap, etc.), but that's more or less the idea.


        thanks,

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Hi Nicolas--

 > Spoon is promising, but won't solve everything.

        I don't think anyone said it would... yet. :)  I think you're
broadening the discussion a bit from what Ralph and I were talking
about. We were just dealing with how to disentangle what is in the
Squeak image right now. Solving this problem is useful all on its own.
Clearly there are other problems to solve as well (like how to support
multiple conflicting applications at the same time).

        But since you raise them...

        Previously, we had no good solutions to the problems you mentioned. I
do think Spoon will put us in a better position to solve them.
Specifically, it will help a lot to have completely unconstrained class
names, to be able to transfer behavior between systems without using
source code, compilation, or files, and to have multiple methods
associated with any given method name.


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Hi Craig -

>     Previously, we had no good solutions to the problems you mentioned.
> I do think Spoon will put us in a better position to solve them.
> Specifically, it will help a lot to have completely unconstrained class
> names, to be able to transfer behavior between systems without using
> source code, compilation, or files, and to have multiple methods
> associated with any given method name.

I'm curious but how exactly does this help for modularity? Since I
haven't used Spoon so far I don't really know what to look for here but
it'd be great if you were willing to share a few success stories, or
even if there aren't any yet just your reasoning about why you think
this abilities are an important step.

Cheers,
   - Andreas

Hi Andreas--

 > > I do think Spoon will put us in a better position to solve [the
 > > problem of multiple co-resident applications clashing].
 > > Specifically, it will help a lot to have completely unconstrained
 > > class names, to be able to transfer behavior between systems without
 > > using source code, compilation, or files, and to have multiple
 > > methods associated with any given method name.
 >
 > I'm curious but how exactly does this help for modularity? Since I
 > haven't used Spoon so far I don't really know what to look for here...

        (If you haven't read them already, you might find the previous Spoon
progress reports[1] interesting.)

 > ...but it'd be great if you were willing to share a few success
 > stories, or even if there aren't any yet just your reasoning about why
 > you think these abilities are an important step.

        The main success story I have with Spoon is in reducing the size of a
complex, unmodularized application (OpenAugment), without having to
analyze how it was put together or what exactly its prerequisites were.
I did this by using imprinting between the large development object
memory where the application originated and a small deployment memory.
My goal was simply to make the application small, but the resulting
artifact provided a useful basis for actually understanding the
architecture of the application and its dependencies.

        By imprinting methods directly, immediately as they were invoked, I was
assured of installing each method and its literals (particularly
classes) in the proper order, and that I wouldn't waste time or space
with things which were already present. You don't get this when using
source code and/or static files for transferring behavior.

        As for the three aspects I mentioned:

- Having unconstrained class names allows each author to name classes
however they please, and makes it easier for code from different sources
to coexist. (We would probably want the development tools to visually
distinguish a class name appearing in source code when the name is
shared by multiple classes, and provide a means for getting more
information about the particular class associated with a particular
occurrence of the name.)

- Being able to transfer behavior directly between systems increases
delivery accuracy. A module isn't much good if, when applied to a target
system, the behavior it is meant to convey is not properly installed.
When the transfer medium is static files, the author effectively has to
guess at what the state of the receiving system will be at installation
time.

        If we use direct negotiation instead, we can be assured of actually
installing the correct behavior, and in such a way that the receiving
system can then act as a provider to any other system. It's amazing how
many current packages only work in one particular release of Squeak (and
usually an unmodified one at that). With this approach, I think we're
much more likely to produce modules that are usable in multiple Squeak
releases, in various states of end-user modification.

        The remote-messaging infrastructure surrounding the use of live module
objects also enables other useful abilities, like browsing and even
running the behavior associated with a module in the providing system
(by opening remote browsers and other tools directly on the providing
system), before ever deciding to install it locally.

- Being able to associate multiple methods with the same method
signature avoids another major source of collisions (and places similar
demands on the tools that unconstrained class names do).


        thanks,

-C

[1] http://lists.squeakfoundation.org/pipermail/spoon

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Hi Craig -

>  > I'm curious but how exactly does this help for modularity? Since I
>  > haven't used Spoon so far I don't really know what to look for here...
>
>     (If you haven't read them already, you might find the previous Spoon
> progress reports[1] interesting.)

Yes, thanks for pointing it out.

That's *very* interesting to me. Modularity is one of those areas where
theory goes only so far and having a practical example is really
important to study real-life implications of the system. For example,
personally I was (well, still am ;-) somewhat hesitant whether
imprinting will be good enough to capture all the corner cases; the
cases that happen "one in a thousand" (like a file not being there) and
may require a set of methods that's not available at runtime (e.g.,
after imprinting). I'm curious - how do you deal with that issue in
practice?

>     By imprinting methods directly, immediately as they were invoked, I
> was assured of installing each method and its literals (particularly
> classes) in the proper order, and that I wouldn't waste time or space
> with things which were already present. You don't get this when using
> source code and/or static files for transferring behavior.

I think you do, just on a different granularity (modules) and not quite
as elegantly ;-) But that's a little besides the point here.

>     As for the three aspects I mentioned:
>
> -    Having unconstrained class names allows each author to name classes
> however they please, and makes it easier for code from different sources
> to coexist. (We would probably want the development tools to visually
> distinguish a class name appearing in source code when the name is
> shared by multiple classes, and provide a means for getting more
> information about the particular class associated with a particular
> occurrence of the name.)

So what does Spoon do to make this work? Does every module have its own
(local) namespace to map names freely to UIDs/classes? (that's what I am
leaning towards for Croquet ;-)

> -    Being able to transfer behavior directly between systems increases
> delivery accuracy. A module isn't much good if, when applied to a target
> system, the behavior it is meant to convey is not properly installed.
> When the transfer medium is static files, the author effectively has to
> guess at what the state of the receiving system will be at installation
> time.

True, but isn't this a different problem? Without the files at the
beginning aren't we risking that we basically arrive at some "fixed
point" for each system that we can't leave without breaking things
horribly? [Not that this really matters at this point but I'm curious
about the philosophical implications here]

>     The remote-messaging infrastructure surrounding the use of live
> module objects also enables other useful abilities, like browsing and
> even running the behavior associated with a module in the providing
> system (by opening remote browsers and other tools directly on the
> providing system), before ever deciding to install it locally.

Yeah, that's a little bit like Croquet when you open a browser on a
replicated portion of code ;-) Except that in Croquet that code is
already there but it would be fairly simple to write a browser which
shows code in a "remote" island (one of the nice things about a remote
messaging framework is how widely it's applicable to various
applications - a Croquet replicated message can trivially be implemented
as a message to a single client on a remote machine).

> -    Being able to associate multiple methods with the same method
> signature avoids another major source of collisions (and places similar
> demands on the tools that unconstrained class names do).

Yes, I think that's essentially the same as the class name/uid
distinction. How do you deal with this problem? (my inclination
currently is to do the same, e.g., have a selector name space per island
and map the messages to UIDs or somesuch).

>     thanks,

This is very interesting, thanks a lot!

Cheers,
   - Andreas

On May 24, 2006, at 4:39 AM, Craig Latta wrote:

> - Being able to associate multiple methods with the same method  
> signature avoids another major source of collisions (and places  
> similar demands on the tools that unconstrained class names do).

Oh? That's an aspect of Spoon I was unaware of. Can you point me  
toward a more thorough description?

Thanks,

Colin

> I
> do think Spoon will put us in a better position to solve them.
> Specifically, it will help a lot to have completely unconstrained
> class
> names, ...

I don't understand this.  What do hard-references to classes in code
bind to then?  For example, two totally different Person classes are
loaded and one code says:

  myPerson := Person new

and other:

  someOtherKindOfPerson := Person new

Ah, is there a conflict-checking operation that dynamically renames one
of them?

Thanks..

Hi Craig

Le Mercredi 24 Mai 2006 06:08, Craig Latta a écrit :
> Hi Nicolas--
>
>  > Spoon is promising, but won't solve everything.
>
>  I don't think anyone said it would... yet. :)  I think you're
> broadening the discussion a bit from what Ralph and I were talking
> about.

Yes, i like to push things a little further.

> We were just dealing with how to disentangle what is in the
> Squeak image right now. Solving this problem is useful all on its own.

I agree, that is already great, and i call it promising when thinking of tools
that we can build above it.
Of course, all my best encouragements for it.

> Clearly there are other problems to solve as well (like how to support
> multiple conflicting applications at the same time).
>
>  But since you raise them...
>

Yes, i was thinking with a programmer's point of view in a monolithic image:
how to identify and resolve these conflicts?

>  Previously, we had no good solutions to the problems you mentioned. I
> do think Spoon will put us in a better position to solve them.
> Specifically, it will help a lot to have completely unconstrained class
> names, to be able to transfer behavior between systems without using
> source code, compilation, or files, and to have multiple methods
> associated with any given method name.
>
> -C

This is a completely different and pragmatic approach: do not resolve source
code conflicts, let them co-exist peacefully...

Something close to typical OS job: loading different binary executable into
separated space processes, maybe with .dll/.so dynamic loading/sharing. But
then we have displaced the problem at interprocess communication level... How
does spoon compare to this model?

Nicolas

Hi Andreas--

 > Modularity is one of those areas where theory goes only so far and
 > having a practical example is really important to study real-life
 > implications of the system. For example, personally I was (well, still
 > am ;-) somewhat hesitant whether imprinting will be good enough to
 > capture all the corner cases; the cases that happen "one in a
 > thousand" (like a file not being there) and may require a set of
 > methods that's not available at runtime (e.g., after imprinting). I'm
 > curious - how do you deal with that issue in practice?

        I liken that risk to the risk one takes in any application deployment.
If you don't have sufficient test case coverage, bugs will slip through
to users. Spoon can help automate the creation of the more common test
cases, but the burden of being "complete enough to ship" is still upon
the human developer, as it always has been. People have written tools to
try to deduce what *might* happen when a system runs, but so far Spoon
doesn't attempt anything along those lines.

 > ...what does Spoon do to make [unconstrained class names] work?

        (Please see my response to Chris.)

 > Without the files at the beginning aren't we risking that we basically
 > arrive at some "fixed point" for each system that we can't leave
 > without breaking things horribly?

        Hmm, I don't think so. Can you give a concrete example?

 > How do you deal with this [overloaded method signatures]?

        (Please see my response to Colin.)

 > This is very interesting, thanks a lot!

        Sure thing! Thanks for the questions.


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

 > I agree, that is already great, and i call it promising when thinking
 > of tools that we can build above it.

        That's the spirit. :)

 > This is a completely different and pragmatic approach: do not resolve
 > source code conflicts, let them co-exist peacefully...

        Indeed, I would argue that they aren't really conflicts. Two methods
might use the same class name to refer to two different classes, but as
long as the methods themselves retain information about the identities
of those classes, we can reason about those references all we like.

 > Something close to typical OS job: loading different binary executable
 > into separated space processes, maybe with .dll/.so dynamic
 > loading/sharing. But then we have displaced the problem at
 > interprocess communication level... How does spoon compare to this
 > model?

        It's very different. All the named entities are in the same space, what
makes things work is that they have separate identities which are
available to us.


        thanks,

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Hi Chris--

 > > ...it will help a lot to have completely unconstrained class
 > > names...
 >
 > I don't understand this.  What do hard-references to classes in code
 > bind to then?

        That machinery is unchanged. The class objects themselves are mentioned
in the literal frames of the methods in which they appear. The execution
machinery doesn't care what their names are, just their object
identities ("Name And Identity Are Distinct"). Any tool that displays
source code can be smart about methods with literal frames that refer to
classes with names shared by other classes (phew).

        Such a tool can render the *source code* of such a method to cue the
reader that such a class does not have a unique name. For example, the
tool could use a hyperlink, which the reader could follow to find out
more about the particular class object used by a method.

 > For example, two totally different Person classes are loaded and one
 > code says:
 >
 >   myPerson := Person new
 >
 > and other:
 >
 >   someOtherKindOfPerson := Person new
 >
 > Ah, is there a conflict-checking operation that dynamically renames
 > one of them?

        No, they both get to keep their identical names. That is to say, both
class objects have #Foo in their "name" slot (said slot currently
defined by class Class). So, we've got two class objects; for the sake
of discussion, let's say that one of them has name #Foo and identity
hash 7777, and the other has name #Foo and identity hash 8888. (Note
that Spoon actually uses metaclass UUID slots to track the identity of
each class/metaclass pair.)

        Now, for the first expression you mentioned, there is a corresponding
method literal that refers to the class with identity hash 7777. For the
second expression, there is a corresponding method literal that refers
to the class with identity hash 8888. There is no effect on the source
code (both expressions simply refer to "Person"), which makes sense
since we can transfer methods between systems without using source code
or compiling anything. When transferring behavior, source code is merely
an annotation for the benefit of human readers (particularly given the
fact that we can decompile methods at will).

        The only compilation that need occur is when authors accept methods
after editing. The browser can easily detect when an author attempts to
compile some source which invokes a name used by multiple classes, and
prompt for disambiguation. The system could, for example, provide a list
of the class categories in which the "Person" classes appear.

        In effect, each class in the system has its own namespace, since all
class names are completely unconstrained all the time in all locations
(i.e., "universally", which really just recapitulates the "universal" in
"UUID" :). It will still be useful to put classes into named groups, for
the purposes of organizing them, but I don't consider such groups to be
namespaces. For one thing, within any such group you can have any number
of classes with the same name. You could give every class in the system
the same name if you really wanted to. :)

        This scheme doesn't really work if behavior moves between systems by
means of source code in files (fileouts), as we've done previously.


        I hope that helps, thanks for asking!

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Hi Colin--

 > > Being able to associate multiple methods with the same method
 > > signature avoids another major source of collisions (and places
 > > similar demands on the tools that unconstrained class names do).
 >
 > Oh? That's an aspect of Spoon I was unaware of. Can you point me
 > toward a more thorough description?

        Sadly, no, not yet; I'll just have to write one here. :)

        The next version of Spoon has a subclass of Symbol, called Selector. (I
use a new Selector class for this so as not to disturb traditional
notions of Symbol identity.) The Selector class implements multiple
selector tables (similar in concept to a normal symbol table). An author
can specify via the tools that a method's selector is not identical to
any existing selector, and so should be in a new table.

        When an author attempts to compile method source that uses a selector
that appears in multiple selector tables, the system asks for
disambiguation (e.g., by presenting the lead comment from the
corresponding method sources). The number of selector tables the system
maintains at any given moment is equal to the number of meanings held by
the most-overloaded method signature in the system, and the system does
reclamation as necessary (via weak references). Method dictionaries use
Selectors as keys, instead of Symbols.

        Again, since behavior is transferred from one system to another without
relying solely on source code, this scheme is feasible.

        I'm not sure how much this feature would actually get used, though. At
this point it's more of a marketing-checklist thing. :)


        thanks,

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

On 5/25/06, Craig Latta <[hidden email]> wrote:

There is a lot of Smalltalk code that says (Smalltalk at: className)
and expects to get a class.  This is more than just a matter of tools,
it is part of the reflective definition of Smalltalk.  Does Spoon get
rid of the global variable Smalltalk?  What about other global
variables?

One solution is to delete the global variable Smalltalk from the
system, but then a lot of code won't work.  A better solution would be
to figure out a simple name-space management system so that most uses
of the global variable Smalltalk will continue to work.

-Ralph Johnson

On 5/23/06, Craig Latta <[hidden email]> wrote:
>  > It is a very good idea.  A module is defined as all the code that is
>  > needed to run a test suite.  To have a module, you must have tests.  I
>  > like it!
>
>        Cool! I expect that there will be some fiddling with that delineation
> (to deal with conceptual overlap, etc.), but that's more or less the idea.

The more I think about it, the better I like the idea of using tests
to define module boundaries.  A module depends on some other modules,
of course.  The other modules are loaded before the tests are run, so
their code will not be counted among the code of the module.  People
can control the code in a module by changing its tests.  The only
problem would be code that is hard to test with automatic tests, such
as an event loop.  However, it should be easy for a test to
explicitely list methods that should be included even though they are
not called.  Do you have a way of doing this already?

Good code needs tests.  Encouraging people to write tests helps them
to write better code.  So, defining modules as "all the code covered
by a test suit" will make the code better, because it ensures that it
has at least minimal tests.

I also like the idea of implementing a module as the objects (classes
and methods) that are traced during execution.  I was at a workshop a
few weeks back that included both Schemers and Smalltalkers.  One
thing that impressed me was that Schemers think a program is a text
file, while Smalltalkers think a program is a set of objects in
memory.  There was one Lisp guy there, and he was more like
Smalltalkers, because he thought of a program as a set of
S-expressions, and the textual representation of S-expressions in
files was secondary.  Lisp is reflective; Scheme is not.  In a
reflective language, the internal representation of a program has
computational meaning.  So, Spoon is very much in line with the
Smalltalk tradition, but in a way that will seem extreme to
non-Smalltalkers.

Like I said in another message, I think you will have to deal better
with class name clashes because the global variable Smalltalk is
important.  I think this will lead to name spaces in Spoon.  I'll post
another message about that later.

-Ralph