About MC for managing the image

[Avi Bryant]

On Sep 18, 2005, at 1:29 PM, Andreas Raab wrote:
>>
>> So I'm proposing to have MCConfigs to use simu-load for users and  
>> simu-merge developers, and ignore any specified order. Avi and  
>> have sketched the needed changes out, I'll work on it soon.
>>
>
> Again, please explain "simu-load" and "simu-merge". This discussion  
> is the first I ever heard about it and I just don't know what this  
> means exactly.
>
> But to summarize: Am I correct in understanding that you are  
> proposing to change loading configs in order to use dependencies to  
> create configurations? If not, I fail to see how this last  
> paragraph relates to dependencies ;-)

I think dependencies are actually a red herring: I think we all agree  
that they're broken and that external configs are a better way to  
go.  So let me focus on the "simu-load/merge" stuff.

At its lower levels - the parts that actually load code into the  
image - Monticello doesn't know anything about packages.  All it  
knows is, basically, "there's this set of definitions in the image,  
and this other set of definitions coming from the outside, and I need  
to adjust the image's set so that it matches the external set".   
Merge works the same way "I need to merge the image's set with this  
other set".

Now, the usual case is that the set of definitions in the image  
corresponds to all of the methods currently in the image in a single  
package, and the set of definitions coming in from the outside  
corresponds to those in a single package version file.  But there's  
actually no reason that has to be so: you can throw as many  
definitions into that pool at once as you want.  So the set from the  
image could be the union of the definitions from several packages, as  
could the set coming in from the outside.

Within that pool of definitions, package boundaries are unknown and  
ignored.  The load order is determined for the pool as a whole, using  
the rules I mentioned earlier.  So if you throw a whole bunch of  
packages into the pool, it will figure out a load ordering at method/ 
class granularity, rather than at package granularity.

Concretely, if you look at MCVersion>>load, it boils down to this:

MCVersion>>load
     MCVersionLoader new
         addVersion: aVersion;
         load

If you want to load more than one version at once, you simply need to  
do this:

MCVersionLoader new
    addVersion: versionA;
    addVersion: versionB;
    load

MCVersionMerger works similarly.

What I'm proposing and Daniel is working on is that we modify  
MCConfiguration to use this mechanism rather than an explicit load  
order.

Avi