I like the way you're thinking - I also feel there is a lot we can learn
from other open source projects of the same "kind" of scope.

I have no doubt that when Squeak has as many users as Debian, we'll need
to support multiple loaded versions of same-named "class libraries".
However, note that this mechanism has it costs - both the complexity
costs and also process costs.

By complexity costs I mean newbie (and not so newbie!) questions like -
"why the same code works in a workspace but not in a package I loaded?".
Having only one namespace prevents us from having to think about this,
which is a feature we might come to miss.

By process costs I mean that namespaces are a mechanism for coexisting
without needing to coordinate. It reduces the incentives to make an
abstraction useful enough that others can reuse it. For example when
we're talking about transitioning out the old streams, it makes it easy
for users of unported applications to simply keep on loading the old
streams package, instead of porting. This is obviously good for the
individual, but it is not as good for a community that needs as many
testers as possible to stabilize a new library. 

What I mean by the last issue is that namespaces don't solve the
integration problem, they just make its pain less direct. Whether this
is more of a benefit than it is a liability I think is a tricky
question.

Daniel

Marcus Denker <marcus at ira.uka.de> wrote:
> 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