"delete", "destroy", "reclaim", and "p->Heaper::~Heaper();"

[Mark S. Miller <vlad!mark>]

Note: ideas here are taken from a variety of sources.  Especially
Michael & Dean.

Here's a summary of my current thinking on rubbing out objects:

1) "delete" only be used on non-Heapers.  For Heapers we consider it
to be obsolete.  With one exception: The Heaper::destroy() method
itself does a "delete this;".  I even know of a sneaky way of checking
for violations of this at run-time, but it's better to do a static
check (if we can).

2) Where we would have normally written "delete p;", we instead write
"DESTROY(p);".  Where we would normally have written "delete expr;" we
write "expr->destroy()".

"destroy()" (like all messages/member function invocations) is a
request.  "delete" is a command--C++ doesn't allow it to be refused.
Voluntarism should be one of the guiding principles of object oriented
programming.

3) Clean-up code that we would normally put in a destructor we
continue to put in a destructor, not in a destroy method.  We only
override Heaper::destroy() in a subclass in order to do nothing--i.e.,
there will be certain objects that refuse to let their clients
actually destroy them.

The reason for this is that there are situations where only the
destructor is invoked, without a "destroy" or a "delete" or even a "by
your leave".  This happens as a result of...

4) Explicit invocation of the destructor: "p->Heaper::~Heaper();".
This destructs the object causing it to vacate its memory, but doesn't
deallocate the memory.  This is done in two places: In the garbage
collector (which, by the landlord analogy, actually does have the
right to force the object to vacate).  And in the "become" code that
I'm writing, in which it is the object's own choice to become
something else.  It must vacate it's apartment without terminating its
lease (i.e. deallocating its memory) in order to have it's heir move
in.  I don't know if C++ let's us use visibility restrictions to
control who may do this to an object (but I'll find out).

5) You say "destroy" to request the immediate object you're talking to
to go poof.  If on the other hand you say "reclaim", then you are not
only asking this object to rub itself out, you are also asking it to
rub out any object it may be a representative for.  Right now we have
two cases where one object is a representative for another: 1) A proxy
is a representative for some actual object on the other side of the
comm link.  2) Both a Shepherd & a ShepherdStub are representatives
for an actual object (actually, the whole flock) sitting on the disk
in a Snarf.

I am actually still unhappy about the destroy/reclaim distinction (it
makes my modularity/transparency detectors itch), but this is what
makes the most sense to me today.  

The other appealing alternative is that we only use "reclaim" on
Shepherds and ShepherdStubs (i.e., only to talk about objects in
Snarfs).  Wrt Proxies over comm, we simply say "destroy" which, if the
pass-by-proxy class declares it in a PROXY section gets forwarded (and
thereby acts as a "reclaim" from the former scheme), whereas if the
pass-by-proxy class doesn't so declare it, then the "destroy" applies
only to the proxy itself.  (This alternative would constitute another
justified purpose in a subclass overriding "Heaper::destroy()".)

Either alternative allows us to remove the current remote destruction
handling from Stubble.  They both work without any special mechanism
in Stubble.