On Mon, 7 Apr 2003, Stephane Ducasse wrote:

> I think that simple way to handle that is to load everything
> atomically: meaning not compile anything before everything is loaded,
> then compile the class with their attributes and finally compile the
> methods.

But it's precisely to be able to load code atomically that I want to do
that analysis.  Right now what Monticello does is this:

- load all the code into memory (but not compile it)
- find the prerequisites of the code
- see if those prerequisites either are already met by the image, or will
be met by the loaded code
- iff all the prerequisites can be met, compile all the code

Right now, however, instance variables aren't considered prerequisites to
methods, even though they will not get compiled properly without those
inst vars existing (and the bugs introduced by that can be really subtle
and hard to find).  I don't want to find out halfway through loading a
patch to a package that some of the method changes depend on inst var
additions that somehow haven't made their way into the patch; I want to
figure that out through static analysis before I compile a line of code.

I would also prefer (but this is just aesthetic, perhaps) not to enforce a
strict ordering like first load all classes, than all inst vars, then all
methods, etc.  I would rather (and currently use) the general rule that
all prereqs must be loaded before a code element can be loaded, and
recursively load these prereqs if necessary.

> About property annotation in our system we can add any new information
> using this approach: the loader catch error and when a message is not
> understood store the values as a tagged properties this way the format
> is open to extensions.

Yes, but you're not actually going from the code model to live code,
right?  Dealing with them at the model level is easy; where do I store
these annotations in the Behaviors and CompiledMethods themselves?

Avi