[ENH] SocketStream ascii/binary and nextAvailable

Marcus Denker marcus at ira.uka.de
Fri Jul 25 07:58:45 UTC 2003


On Fri, Jul 25, 2003 at 12:03:55AM +0200, Andreas Raab wrote:
> Daniel,
> 
> Certainly true for the "bits and pieces" surrounding the design, but
> considering that (for example) Flow is an entire replacement of the stream
> hierarchy, it doesn't solve the problem that some things will (have to)
> break during the migration process. The most important part for me in this
> area is to be able to have a clearly defined migration path which leaves
> things "working by default" while things are being migrated (similar to the
> deprecation machinery used by KCP) can be used in parallel with the set of
> classes being out-phased (that's why I said don't touch the existing stuff)
> and then easily switched over once the major part of migration is finished.
> 

Somehow I have the feeling that there's more to this problem then ensuring
a process: This is one of the kinds of problems that is trying to tell
we need to change something to really solve it. 

Let's see, how so others do this? Squeak is very much like an OS, so
what we need to look at is not a single language, but the language
and the OS support. In a C-based System like Linux it is perfectly
fine to have two different versions of a single library installed,
and Programm A can use the old version while another programm is
running that has allready been changed to use the new version. Really
the new version, not an intermediate-new version with prefixes tagged
on all names...

This is the way we can do this in Squeak today: Build the new Library
of Classes with a prefix: you'd use NewStream or Stream. 
This is not nice... 

It would be better to make it possible to have multiple version of a single 
class installed in parallel... and the client could choose the "perspective"
it needs. This would enable experiments with *real* changes to the System
(because only your testclass would see this new, buggy view. The Debugger
would use the old, proven view on the system). 

(This idea is pretty old, see the papers about US and PIE)

There are a lot of opne questions how to actually (and practically)
implement such a system... but I feel that having something like
this is really important for a System that's supposed to change:
Squeak's only goal is to build the "next system". It's somewhat
ironic that we have worse mechanism for supporting evolution
than the static C world... 

Alexandre's classboxes seem to me a very interesting step
into this direction: In his system (as much as I understand it)
it is possible to have two classes with the same name installed,
in differnt classboxes. And the client can decide which classbox
it wants to import, thus two subsystems can use the differnt classes
at the same time. 

     Marcus


-- 
Marcus Denker marcus at ira.uka.de  -- Squeak! http://squeak.de



More information about the Squeak-dev mailing list