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)]