Dave, could you please repost these links?  I couldn't find them in the
squeak ML archives.

thank you,
Rob

> -----Original Message-----
> From: Dave [mailto:dave at bedarra.com]
> Sent: Monday, August 20, 2001 9:06 PM
> To: Les Tyrrell
> Cc: squeak-dev at lists.squeakfoundation.org; modsqueak at bluefish.se
> Subject: Re: [Modules] Unloading and Conflicting Versions
> 
> 
> 
> 
> 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
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010821/5962b9b9/attachment.htm