Persistent Segments

Les Tyrrell tyrrell at canis.uiuc.edu
Wed Feb 21 22:23:13 UTC 2001


Jecel wrote:
> > If you are changing your own system, you would normally copy the Squeak
> > Central segments you want to change or maybe copy the whole Squeak
> > Central database (similar to an image download today).  Using Squeak
> > Central mirrors in your image is like automatically saying yes to any
> > updates they release.  If your not changing String but just using String
> > I would argue that it is good to see its updates right away, if you want
> > your code to keep up with Squeak releases.
> 
> What happens when you need to run an application which uses a modified
> String class *and* another which uses the original String at the same
> time? I know that can't really be done in the current Squeak, though
> there are efforts to make projects work this way and Collage might be a
> future solution (http://minnow.cc.gatech.edu/squeak/745)

With selector namespaces this perhaps will not be a problem.  Allen
Wirfs-Brock
pointed this out to me at OOPSLA, and when I went back to read his paper
on
the subject it suddenly made sense.  I don't yet have this implemented
in Oasis,
( http://oasis.canis.uiuc.edu:8080/Oasis ) but I am strongly confident
that it
would work.  This particular problem is among the last of the ornery
problems
that I had yet to work out- so I am quite grateful for the hints that
I've
recieved from some others who've done this sort of thing before.

In a nutshell, here's what would happen: suppose you have two modules,
one the Base, and the other the Alien.  The Alien is something that you
downloaded off the web and want to run, the Base is your Base system
that
you don't want to change.  Both have methods for String defined within
them,
to keep it simple let's assume the Alien redefines pre-existing methods
and
depends on those changes to operate correctly, and that these changes
will
lead to the Base not working.  Sounds bad... but not in Smalltalk.  In
Smalltalk, everything is an object- and that is a very powerful
statement.
Everything is an object- including Symbols, which are the keys used for
method lookup.  Each module can have it's own Symbol space.  The symbols
in the Alien module are the ones that the Alien has in it's own methods-
so the redefined methods in String are keyed using Alien's symbols.  NOT
the symbols from the Base.  Likewise, those keys do NOT appear in the
Base
module's symbol space.  THEREFORE... there is no conflict, even if the
symbols
have the same glyph.  So... when you create a system composed of both
the Base
and Alien modules, then the String class which represents the
combination of
those two modules can have multiple methods which "appear" to have the
same
selector- but which are keyed using different symbols ( Symbols are just
objects,
remember- therefore, two symbols having the same glyph are still
different objects,
and can therefore have a different hash ).  Thus, to instances of the
Alien
module, String behaves one way, while to instances of the Base module,
String
retains the original behavior.

Back when I first started thinking about this sort of thing, I
originally
wondered what would be the proper thing to do from the human standpoint-
that is, should objects that migrate across module boundaries retain
their
home module behavior, or should they adopt the behavior of the module
that
they enter?   The analogy I used for myself was what should a person do
when travelling to a foreign land- continue behaving as though they are
still
at home, or according to the local customs of the nation they are
visiting?
I decided that the general expectation would be that out of courtesy we
would expect the visitor to adopt the local behaviors of the land they
are visiting, rather than expect the land they are visiting to adapt to
the customs of the nation they are from.  But, at first this also seemed
to be a difficult thing to do with objects- much easier to implement
if they retain the behavior of the home environment, though that would
seem
to be at odds with our human expectations.  With a few hints in the
right
directions, I now think that this is actually a trivial problem.

- les





More information about the Squeak-dev mailing list