<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [Modules] Unloading and Conflicting Versions</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><A
href="http://swiki.squeakfoundation.org/squeakfoundation/31">http://swiki.squeakfoundation.org/squeakfoundation/31</A></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<DIV><SPAN class=705445418-21082001><FONT face=Arial color=#0000ff
size=2>marcio</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader><FONT face="Times New Roman"
size=2>-----Original Message-----<BR><B>From:</B> Withers, Robert
[mailto:rwithers@quallaby.com]<BR><B>Sent:</B> August 21, 2001 2:21
PM<BR><B>To:</B> 'squeak-dev@lists.squeakfoundation.org'<BR><B>Cc:</B>
modsqueak@bluefish.se<BR><B>Subject:</B> RE: [Modules] Unloading and
Conflicting Versions<BR><BR></FONT></DIV>
<P><FONT size=2>Dave, could you please repost these links? I couldn't
find them in the squeak ML archives.</FONT> </P>
<P><FONT size=2>thank you,</FONT> <BR><FONT size=2>Rob</FONT> </P>
<P><FONT size=2>> -----Original Message-----</FONT> <BR><FONT size=2>>
From: Dave [<A
href="mailto:dave@bedarra.com">mailto:dave@bedarra.com</A>]</FONT> <BR><FONT
size=2>> Sent: Monday, August 20, 2001 9:06 PM</FONT> <BR><FONT size=2>>
To: Les Tyrrell</FONT> <BR><FONT size=2>> Cc:
squeak-dev@lists.squeakfoundation.org; modsqueak@bluefish.se</FONT> <BR><FONT
size=2>> Subject: Re: [Modules] Unloading and Conflicting Versions</FONT>
<BR><FONT size=2>> </FONT><BR><FONT size=2>> </FONT><BR><FONT
size=2>> </FONT><BR><FONT size=2>> </FONT><BR><FONT size=2>> 1. The
mechanism for unloading is indeed a good deal more complex than</FONT>
<BR><FONT size=2>> loading and was one of the throny problems OTI had to
address in</FONT> <BR><FONT size=2>> building embedded Smalltalk and Java.
</FONT><BR><FONT size=2>> </FONT><BR><FONT size=2>> Perhaps the issue of
unloading is something to be deferred until after</FONT> <BR><FONT size=2>>
the basic module and component mechanisms are defined and tested?
</FONT><BR><FONT size=2>> </FONT><BR><FONT size=2>> 2. To my knowledge
the only existing system that supports current</FONT> <BR><FONT size=2>>
execution of multiple versions classes/methods is MS.NET with their</FONT>
<BR><FONT size=2>> assemblies. This itself gets problematic however if you
want to run</FONT> <BR><FONT size=2>> shared assemblies. I posted the
references earlier for those </FONT><BR><FONT size=2>> interested</FONT>
<BR><FONT size=2>> in the problem. </FONT><BR><FONT size=2>>
</FONT><BR><FONT size=2>> Regards,</FONT> <BR><FONT size=2>> Dave</FONT>
<BR><FONT size=2>> </FONT><BR><FONT size=2>> </FONT><BR><FONT
size=2>> Les Tyrrell wrote:</FONT> <BR><FONT size=2>> >
</FONT><BR><FONT size=2>> > ----- Original Message -----</FONT>
<BR><FONT size=2>> > From: Dan Moniz <dnm@pobox.com></FONT>
<BR><FONT size=2>> > > I'm imagining that when you file
in a ChangeSet (let's </FONT><BR><FONT size=2>> say Foo.cs)</FONT>
<BR><FONT size=2>> > > into your image (Bar.image), your
image is writing out </FONT><BR><FONT size=2>> information to</FONT>
<BR><FONT size=2>> > > it's Bar.changes file that reflect
the things Foo.cs is </FONT><BR><FONT size=2>> doing to your</FONT>
<BR><FONT size=2>> > > image. Then, to back out, you
could use a currently </FONT><BR><FONT size=2>> fictional "Undo"</FONT>
<BR><FONT size=2>> > > feature which would allow you to
back up steps as recorded in</FONT> <BR><FONT size=2>> >
> Bar.changes</FONT> <BR><FONT size=2>> > </FONT><BR><FONT
size=2>> > There are a few things that would need to be done when
</FONT><BR><FONT size=2>> unloading a module. For</FONT> <BR><FONT
size=2>> > one, you would like a rapid way of gc'ing or otherwise
</FONT><BR><FONT size=2>> mutating any instances</FONT> <BR><FONT
size=2>> > defined by that module. Then, you will want a rapid way
of </FONT><BR><FONT size=2>> removing the</FONT> <BR><FONT size=2>> >
definitions found in that module. ChangeSets are no </FONT><BR><FONT
size=2>> better, and no worse, at</FONT> <BR><FONT size=2>> > doing
this than any other scheme. There is no need to </FONT><BR><FONT
size=2>> iterate over a change</FONT> <BR><FONT size=2>> > log- the
ChangeSet already has an accounting of what it has </FONT><BR><FONT
size=2>> modified. So would</FONT> <BR><FONT size=2>> > an
OasisModule, or a Collage Layer.</FONT> <BR><FONT size=2>> >
</FONT><BR><FONT size=2>> > However, while associating a ChangeSet with
either a </FONT><BR><FONT size=2>> Collage Layer or an</FONT> <BR><FONT
size=2>> > OasisModule seems reasonable to me, trying to warp
</FONT><BR><FONT size=2>> ChangeSet into becoming more</FONT> <BR><FONT
size=2>> > like these things does not seem reasonable.</FONT> <BR><FONT
size=2>> > </FONT><BR><FONT size=2>> > > This may
necessitate modifications to userland tools to </FONT><BR><FONT size=2>>
deal with</FONT> <BR><FONT size=2>> > > .changes file,
and perhaps some modification to the information</FONT> <BR><FONT size=2>>
> > and/or format of information stored in .changes files,
</FONT><BR><FONT size=2>> but I don't</FONT> <BR><FONT size=2>>
> > think it would be too drastic and I don't think it
</FONT><BR><FONT size=2>> would have much</FONT> <BR><FONT size=2>>
> > with the implementation of ChangeSets themselves.</FONT>
<BR><FONT size=2>> > </FONT><BR><FONT size=2>> > What's wrong with
the idea of implementing the roles of a </FONT><BR><FONT size=2>>
Components and</FONT> <BR><FONT size=2>> > Modules? In Oasis, a
Module is a component that keeps </FONT><BR><FONT size=2>> track of Shared
Globals,</FONT> <BR><FONT size=2>> > Undeclared variables, Pools, and a
few other things. </FONT><BR><FONT size=2>> ChangeSets don't do
this.</FONT> <BR><FONT size=2>> > </FONT><BR><FONT size=2>> > The
role of a changeset is to keep track of changes... the </FONT><BR><FONT
size=2>> role of an</FONT> <BR><FONT size=2>> > OasisModule is to act
as a place in which those changes </FONT><BR><FONT size=2>> take
effect. These are</FONT> <BR><FONT size=2>> > separate roles, so I
would not reccomend mixing them. </FONT><BR><FONT size=2>> ChangeSets
are just fine</FONT> <BR><FONT size=2>> > the way they are, at least in
the sense of the scoping of </FONT><BR><FONT size=2>> their
responsibilities</FONT> <BR><FONT size=2>> > to tracking changes, and no
more.</FONT> <BR><FONT size=2>> > </FONT><BR><FONT size=2>> >
Using ChangeSets as a means of identifying chunks of code </FONT><BR><FONT
size=2>> to turn into a package</FONT> <BR><FONT size=2>> > is
another issue, as far as I know there is nothing wrong with that.</FONT>
<BR><FONT size=2>> > </FONT><BR><FONT size=2>> > - les</FONT>
<BR><FONT size=2>> </FONT><BR><FONT size=2>>
</FONT></P></BLOCKQUOTE></BODY></HTML>