stubble misfeature and a fix

[Eric Dean Tribble <tribble>]

> I want Shepherds to send themselves to the disk as
   > Stubs, Forwarding objects to send themselves to the disk as pointers
   > to other locations, transparent forwarders to send themselves as the
   > obect they are forwarding to, etc.

   Shepherds should not send themselves to the disk as stubs.  Stubs are
   created when a >pointer< to a Shepherd is called from the disk, not
   when the Shepherd is called from the disk.  They exist solely for the
   pointer to have a kindOf(Shepherd) to point at, which calls the actual
   Shepherd from the disk if it is finally needed.  Stubs themselves should
   never be sent to the disk at all, since they represent an actual object
   (in pickled form) that is already on the disk.

Stubs get sent to the disk to represent pointers from one flock to
Shepherds of other flocks.  When they come back, the Stub recipe
returns the actual other objects if it's already imaged, otherwise it
will create (anmd share between all references to the same disk
object) a single Stub for that disk object.

   What are "Forwarding objects"?  (You already covered transparent forwarders,
   and the condition that persists for a while after a flock moves from one
   snarf to another isn't represented by an object.)

yes it is.  i currently store a ShepherdLocation object that tells me
where that other objects moved to.

   Your smalltalk image has not tracked the changes wjr and I are making to
   X++ transceivers, stubble, and the like.  We did something very much
   like what you describe.

   The extra object is no longer created.  (The hair associated with the
   extra object causes snarls in the memory management and deletion
   semantics.)  Instead, the Xcvr asks the object whether it is byProxy,
   and if it is the Xcvr sends the representation of its proxy, and asks
   the object to send the copy portions (if it is a mixed copy/proxy object).  

I can't decide if this is better or worse :-)  The byProxy
deliberately chooses which piece of some algorithm to run, hidden in a
completely different part.  This is actually akin to something I just
stopped doing:  The snarf Xcvr's handled Shepherds specially,
(creating a ShepherdStub and sending it to the disk).  I have to use a
special method (basicSend:) to avoid tyhe special handling a Shepherds
so that the shepherd that actually belongs to a flock can be written out.

   This is in keeping with a different conceptual division of responsibility.
   Objects do not "send themselves".  Xcvrs "send them", and the objects
   assist by informing the Xcvrs of their contents and other tidbits.
   Xcvrs and handlers together make the decisions about what sort of object
   is sent.  (The upside is that knowlege about protocol is more localized.
   The downside is that adding new protocol means augmenting the contents of
   the "protocol can", rather than adding it as part of the new objects that
   use it.)

What are handlers?  Your description above sounds like a distributed
algorithm.  The more I think about it, the more the sending to disk
problem sounds very similar to the problems we had with conversions:
both the XCVRs and the objects want some input into how the object
gets sent.  Hmmm...

   > The solution will
   > be more modular because we can avoid extracting the category from an
   > object.  I really want to keep getCategory as a protected function.

   You're too late.  getCategory() has been exposed (it was never really
   hidden), and the use of the exposure has propagated down both sides of
   the Xcvr fork.  (In principle it would have been possible to hide it
   correctly, rather than expose it, but the decision was to reduce the
   overhead.)

Sunk costs are sunk costs.  This is hardly a reason to advocate it.  I
suggest we avoid it whereever we can!

dean