Re: stubble misfeature and a fix

[Michael McClary <michael>]

> From: tribble (Eric Dean 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.

Transparent forwarders should send themselves as what they are forwarding
to, of course, or they wouldn't be transparent.

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.)

> Right now
> transceivers write out the name of the category of an object, then ask
> the objects to send themselves.  For all the stuff I'm doing, this is
> much too late. []

> The already existing case is that
> object from proxy classes should send a proxy object across the wire
> rather than them selves.  

> This solution both more efficient and more modular than the current
> solution.  The current solution of sending 'makeProxy' to any object
> that goes over the wire requires an extra object creation for every
> proxy transferred object.  I had to adopt a similar soluitioin for
> writing Shepherds out as stubs, and it also requires another objects
> creation for every stub pointer written to disk.

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).  

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.)

> 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.)

	michael