craig at netjam.org
Wed May 24 08:39:58 UTC 2006
> > 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 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
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).
improvisational musical informaticist
Smalltalkers do: [:it | All with: Class, (And love: it)]
More information about the Squeak-dev