[Modules] Unloading and Conflicting Versions

Dave dave at bedarra.com
Tue Aug 21 01:06:03 UTC 2001


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




More information about the Squeak-dev mailing list