Hi Eliot,


On Wed, Dec 27, 2017 at 09:41:49PM -0800, Eliot Miranda wrote:
> Hi David,
> 
> 
> > On Dec 27, 2017, at 9:37 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > 
> > Hi David,
> > 
> >    compiledCodeClassNames  is a mistake.  There are no restrictions on the number of subclasses of CompiledCode.  What tells us if a class is that if code is its format which is expressed in the type information in its class definition, /not/ its name.
> > 
> > _,,,^..^,,,_ (phone)
> 
> If your intent is to ease moving Code between Spur and prior versions then
> a) provide some special case for importing prior code, but do not impose that restriction on the current versions. 
> 
> b) Both the prior version and Spur express the compiled codeness of a class in the class's format, with the name being merely incidental.  One can back port the work to express that through the class definition.
> 

The failure occurs when reading an MCZ into a V3 image, when MCStReader>>classDefinitionFrom: 
creates a new MCClassDefinition from the information provided in a PseudoClass instance. The
PseudoClass does not contain the necessary information about compiled codeness.

This code path does not seem to be followed in a Spur image, I'm not entirely sure why.

> Restricting the code loader by recognizing specific class names puts toad blicks in the way of future code.  It is worse than isKindOf:
>

I agree but don't have a better solution to offer. It would be possible to
use to the actual class to which the PseudoClass refers, but I fear this
would not work in the case of a MCClassDefinition for a class that does not
yet exist in the image.

Dave