Great analysis, Ned.

Still, note that using PI subclasses means that you either must compile
code in order to process the PI, or you must plan to replace a bare PI
with a PI subclass when a package gets loaded.

Since there really seem to be two parts of a package -- the part that
makes sense before a package is loaded, and the part that makes sense
only when it has been loaded -- it would seem to make sense to have two
objects.  The latter part can then make lots of references to package
internals, because it will know the code has actually been loaded.

But, swizzling PI's in place of each other as packages are loaded and
unloaded, also appears to work fine.  Are you thinking of basing it on
become: ?


I think the following restrictions might be harsher than necessary:

> That is, we wouldn't allow extension of the 
> instance variables in PI subclasses, and we also would require that the 
> methods used to report metadata wouldn't be overridden. So we serialize and 
> deserialize the PI instances as instances of PackageInfo, *not* as 
> subinstances.

Still, some restrictions need to be there, it seems.  I am glad people
are generally agreeing that overriding #classes and the like is not
worth the extra flexibility.


Style questions aside, let's be careful about how the serialization
happens.  Dumping a PI with SmartRefStream is great for prototyping, but
may cause maintenance problems down the road if we ever modify what
variables a PI has.  It seems better to design a package format that can
last over time. That might mean something as dumping some nested arrays
of strings using SmartRefStream.  Or it could be done with XML, if we
don't mind it running slowly.  Either way, it is good to really *design*
file formats (and network protocols) if they are intended to last over
time, instead of simply dumping the object model to disk.


Lex