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
|