[Modules] Unloading and Conflicting Versions

Marcio Marchini marcio at bedarra.com
Tue Aug 21 18:55:12 UTC 2001


RE: [Modules] Unloading and Conflicting
Versionshttp://swiki.squeakfoundation.org/squeakfoundation/31

marcio
  -----Original Message-----
  From: Withers, Robert [mailto:rwithers at quallaby.com]
  Sent: August 21, 2001 2:21 PM
  To: 'squeak-dev at lists.squeakfoundation.org'
  Cc: modsqueak at bluefish.se
  Subject: RE: [Modules] Unloading and Conflicting Versions


  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/d51ce809/attachment.htm


More information about the Squeak-dev mailing list