I compare some of the this to the current situation with global references. It is easy to get the image into an
inconsistent state and it even keeps running. BUT there are tools that make it easy to find and current this.  Adding
modules together with imports and exports results in more ways the image can be inconsistent but rather than try and
prevent them the focus should be on tools to find and correct them.

Joerg
-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Dave
Sent: August 21, 2001 4:55 AM
To: Allen Wirfs-Brock
Cc: squeak-dev at lists.squeakfoundation.org; modsqueak at bluefish.se
Subject: Re: [Modules] Unloading and Conflicting Versions


I agree this too is "hard" and agree that for any useful image based
system there
needs to support for a limbo state.

Allen Wirfs-Brock wrote:
>
> Actually, what's really hard is what Team/V called "migration".  That is
> taking a module or set of modules and atomically replacing them with
> different versions of the same modules.  Envy does something similar.  In
> VisualAge Java they call it "replace".
>
> While it's hard, I see this a pretty essential operation in a collaborative
> development environment.  It's one of those things like working with
> incomplete or inconsistent modules that isn't strictly necessary for
> deployment but is integral to incremental development.
>
> Alllen
>
> At 09:06 PM 8/20/2001 -0400, Dave wrote:
>
> >1. The mechanism for unloading is indeed a good deal more complex than
> >loading and was one of the throny problems OTI had to address in
> >building embedded Smalltalk and Java.
> >
> >Perhaps the issue of unloading is something to be deferred until after
> >the basic module and component mechanisms are defined and tested?
> >
> >2. To my knowledge the only existing system that supports current
> >execution of multiple versions classes/methods is MS.NET with their
> >assemblies. This itself gets problematic however if you want to run
> >shared assemblies. I posted the references earlier for those interested
> >in the problem.
> >
> >Regards,
> >Dave
> >
> >
> >Les Tyrrell wrote:
> > >
> > > ----- Original Message -----
> > > From: Dan Moniz <dnm at pobox.com>
> > >   > I'm imagining that when you file in a ChangeSet (let's say Foo.cs)
> > >   > into your image (Bar.image), your image is writing out information to
> > >   > it's Bar.changes file that reflect the things Foo.cs is doing to your
> > >   > image. Then, to back out, you could use a currently fictional "Undo"
> > >   > feature which would allow you to back up steps as recorded in
> > >   > Bar.changes
> > >
> > > There are a few things that would need to be done when unloading a
> > module.  For
> > > one, you would like a rapid way of gc'ing or otherwise mutating any
> > instances
> > > defined by that module.  Then, you will want a rapid way of removing the
> > > definitions found in that module.  ChangeSets are no better, and no
> > worse, at
> > > doing this than any other scheme.  There is no need to iterate over a
> > change
> > > log- the ChangeSet already has an accounting of what it has
> > modified.  So would
> > > an OasisModule, or a Collage Layer.
> > >
> > > However, while associating a ChangeSet with either a Collage Layer or an
> > > OasisModule seems reasonable to me, trying to warp ChangeSet into
> > becoming more
> > > like these things does not seem reasonable.
> > >
> > >   > This may necessitate modifications to userland tools to deal with
> > >   > .changes file, and perhaps some modification to the information
> > >   > and/or format of information stored in .changes files, but I don't
> > >   > think it would be too drastic and I don't think it would have much
> > >   > with the implementation of ChangeSets themselves.
> > >
> > > What's wrong with the idea of implementing the roles of a Components and
> > > Modules?  In Oasis, a Module is a component that keeps track of Shared
> > Globals,
> > > Undeclared variables, Pools, and a few other things.  ChangeSets don't
> > do this.
> > >
> > > The role of a changeset is to keep track of changes... the role of an
> > > OasisModule is to act as a place in which those changes take
> > effect.  These are
> > > separate roles, so I would not reccomend mixing them.  ChangeSets are
> > just fine
> > > the way they are, at least in the sense of the scoping of their
> > responsibilities
> > > to tracking changes, and no more.
> > >
> > > Using ChangeSets as a means of identifying chunks of code to turn into
> > a package
> > > is another issue, as far as I know there is nothing wrong with that.
> > >
> > > - les