Packages (Re: Radical suggestions)

Les Tyrrell tyrrell at canis.uiuc.edu
Thu Jul 15 15:43:39 UTC 1999


As a practical consideration...

It is possible, and I have seen this happen, for different third party
code to not only extend existing classes by adding new methods, but
also to overwrite the same previously existing method.  One can argue
about the gracefulness or lack thereof of this, but it does happen, and
in commercially available code.  In extreme cases, the code will also
redefine existing classes.  You don't see so much of this due to the
fact that it usually becomes quickly apparent to all parties that something
has been done against the grain of the system.  But it does happen,
especially when porting code from other Smalltalk dialects.  For instance,
just try to define a new class Link in VisualWorks... go ahead, I triple-dare
you!

Christian Brunschen's proposals about the packages are entirely reasonable.
There are various weak forms of this in existing commercial implementations,
for instance Parcels in VisualWorks keep track of the changes they make to
existing classes, but do not live in a world with namespaces ( at least not
until recently ).

The biggest semantic problem one has in doing something similar to Brunschen's
proposal is determining what the proper behavior of an object ought to be as
it crosses module boundaries.  Should it maintain it's own defined behavior
( from an implementation standpoint, the easiest approach- the object retains
it's class relationship to the class from which it was instantiated ) or should
it in fact change behavior ( literally- the class relationship must change
for this to work ).  As a hunch, I believe that the first option would be
adequate, especially if one separates the notion of modularity into at least
two kinds - one being the notion of packages of componenents, the other in the
sense of breaking up an image into distinct regions, or systems, which have
well-defined ports through which objects pass.

There are lots of good reasons for doing these sorts of things- for instance,
how would you protect yourself if you wanted to bring in some risky code?
The only way is to start a new image and try the code there.  But another
approach would be to open a new, appropriately constrained world within
an image, a world configured by picking and choosing various components
from various component libraries.  I routinely have several dozen images
from various dialects lying about for no other reason than that I wanted
a place to try something out without trashing my primary development image.
This gets expensive and difficult to manage- I would much prefer being able to
do this sort of thing safely within a single image. 

les





More information about the Squeak-dev mailing list