Distributed Squeak and Environments

Karl Ramberg karl.ramberg at chello.se
Thu Jun 21 04:40:15 UTC 2001


Jecel Assumpcao Jr wrote:
> 
> On Wednesday 20 June 2001 10:13, Anthony Hannan wrote:
> > Thanks for the encouragement.
> 
> I think this is a key step in solving Squeak's pink/blue dilemma, as I
> explain below.
> 
> > > While associating environments with processes is also a good idea,
> > > we only have one process for the GUI and that is a problem.
> >
> > No its not, a process can change environments by doing:
> > [x doSomething] valueIn: anEnvironment.
> 
> Great! That does the trick nicely. The Us language has a special
> (non-ASCII) operator for changing "viewpoints" and I had suggested that
> blocks and a keyword selector would work just as well (I called mine
> #asSeenBy:).
> 
> The reason I claimed you have a solution to the problem of maitaining
> compatibility while advancing in new directions is that you added a new
> dimension to inheritance:
> 
>    a class doesn't have to implement stuff that is in its superclasses
> 
>    a class doesn't have to implement stuff that is in its "super
> environments"
> 
> Imagine that I have a set of classes in an environment called
> Collections2.7 and the same classes in another environment called
> Collections3.1 and the latter "inherit" from the former. With some
> care, I would be able to run the very latest stuff and still run old
> things knowing for sure that they won't break. Stable and advanced at
> the same time.
Hans Martin Mosner has been working on a system called Collage
that would do some of this. 
http://minnow.cc.gatech.edu/squeak/745

Karl
> 
> The image would not be that much larger than what we have currently
> since Collections3.1 only has to include what Collections2.7 does not.
> The changes files gives us a good idea of how much bloat we would have.
> 
> -- Jecel





More information about the Squeak-dev mailing list