On Tue, 8 Apr 2003, Stephane Ducasse wrote:

> Because you could have the same problem with method invocation. You
> load a method
> foo>>
> 	self x y zz bar
>
> and bar does not exist!

No, that's different.  It's perfectly legal (and the behavior is very well
defined) to have a method sending a selector that does not exist (or
referencing a global that's not declared, for that matter).  Using a
missing instance variable seems to cause undefined behavior, however.
It certainly doesn't throw any nice exception like MNU.  So I'd really
like to catch that at load time.

> But the load in one phase and the treatment of the load entity is
> another one. So the order could be irrelevant still the check have to be
> done in order.

Yes, but then you have to do the check at load time.
Honestly I don't think that check will be *that* big a deal.  The Parser
should be able to give me the information I need.

> Good question. I think that the trick of Joseph was to have in the
> dead-entities (MethodDefinition, ClassDefinition....)
> the information extracted from the load file, then put back in the
> living entities as much information, but as the tools were working on
> the dead-entities (or via the dead-entities (MethodDefinition) to the
> living one (CompiledMethod) ) he could control exactly where the
> information was kept.

Right, I think eventually we'll want a system where both live and dead
entities are kept in memory, and the tools work primarily on the dead
ones.  For now, however, people are used to loading the dead entities into
live entities, working with the live entities, and then recreating the
dead entities from them.  So any information in the dead entities needs to
be able to be round-tripped through the live ones.

Avi