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