shower strikes again (whap!)

[Eric Dean Tribble <tribble>]

Wait a second.  That's not true, at least for the version I'm doing.
I think this decision is in the SnarfPacker.  How does the stuff you
are working on touch this?  (Stub generation scripts?)

   Why should there be multiple stubs in-ram for the same out-of-ram
   object?  All the pointers which caused the stubs to exist came into
   existence by pointing to the same object.  The creation of the stub
   is mediated by the ViewHandler/Snarf(Un)Packer, which knows where all
   the already-in-ram stubs and disk-wise shepherds are, and can as easily
   hand back a pointer to one that exists as cause creation of a new one.

Yes the SnarfPacker handles it and could keep track of these objects,
but then it has to keep track of approximately 4 times as many
objects.  Therefore I've been assuming that stubs are extremely
lightweight and don't get indexed in the SnarfPacker.

   If objects can't be changed, then changing a stub into a transparent
   forwarder of the appropriate subclass doesn't work either.  We could
   work around that by insisting that no subclass of a shepherd represented
   by a concrete stub can implement a new message, but that's dirty.

I think part of the ent requires a subclass with more messages.  I'd
rather not recode it :-)

   Great!  Are there any things that mutate while being pointed at by half
   the world?  (Changing the annotation on the inter-snarf pointers that
   point at them could require pulling in lots of snarfs, which would be bad.
   On the other hand, I suspect we don't now have any ent-objects that change
   type in-place, or we wouldn't be having this conversation, right?  B-) )

MY TERMINAL'S WEDGED.  PLEASE IGNORE THE UPPERCASE.
THE ANNOTATIONS MUST BE ONLY COMPILE-TIME TYPE INFORMATION, AND THAT
CAN'T CHANGE, SO WE SHOULDN'T HAVE TO CHANGE ANNOTATIONS ANYWHERE.

DEAN