How it works
Last updated at 12:24 pm UTC on 17 January 2006
Regarding ordering of methods/classes in the MC files
Situation One of the methods in VMMaker is #touch which is sent as part of the noteCompilationOf:isMeta: override in InterpreterPlugin. Because this got filed out in advance of the implementation of #touch, I used a sar preamble to add a dummy #touch to Object, then removed it in the postscript. You may be able to suggest an alternative to this. I imagine filein ordering must have been an issue somewhere in your MC experience.
Explanation Monticello has a fairly generalized ordering system where each definition can provide a list of symbols/classes/whatever that it "provides" as well as a list that it "requires", and MC will make sure that things aren't loaded until all their requirements are provided. So the trick would be to somehow annotate #noteCompilationOf: that it required #touch, so that the ordering would happen correctly. Every time I bring up method annotations somebody complains, but if anyone can suggest a generally acceptable mechanism of recording this information I will happily build it into MC.
That sort of thing really shouldn't be necessary though. It's only an issue in this case because #noteCompilationOf:meta: is a compiler hook; normally the compilation of methods doesn't depend on other methods already being present.
And here we find ourselves wading into deep water, because the proper way to handle this is as much a matter of philosophy as anything else. With Monticello, we've tried to walk a middle ground between the imperative and declarative approaches, but this is one area where we'll have to make a choice: a snapshot is either a program that bootstraps its self into existence or it's an inert description of a program that requires another program to load and run it.
If we opt for the former, we need to special case #noteCompilationOf:meta: (and other such meta-level hooks) so that it gets loaded first, and can participate in the loading of the rest of the snapshot.
If the latter, we need to move toward atomic loading of snapshots, with carefully defined semantics for initialization and finalization.
HMM sez: I would very much favor compilation of all methods without installing any, and then atomically installing all of them (which is a completely declarative approach). That should be possible without too much hassle using current Squeak compiler technology.
True compiler hooks should be modeled with package dependencies - there should probably be two kinds of such dependencies:
- for normal situations, load the package atomically together with its prerequisite.
- for compiler hooks, load the prerequisite first, because it modifies the system to make the package loadable at all.
