DSPTRs & stuff (was: "rewriting proxies' sending half")

[Mark S. Miller <vlad!mark>]

Date: Sun, 12 Aug 90 20:13:18 PDT
   From: xanadu!michael (Michael McClary)

   ...

	   SPTR(Type) instance = ...;
	     ...
	   Type * temp = instance;
	   instance = NULL;
	   delete temp;

   This is a candidate for an inline member function, thus:

	   SPTR(Type) instance = ...;
	     ...
	   instance.deleteContents();

How about "#define DESTROY(p) { (p)->destroy(); (p) = NULL }"?

   ...
   This way the code would read:

	   {
		   DSPTR(Type) instance = ...;
		     ...
	   }

I really *really* like the DSPTR suggestion.  This simple mechanism
would completely replace the need for the MORTAL macro and the
"mortal" module.  And be much cheaper too.  The use of this is not
simply to off-load the garbage collector.  There are situations where
it would be incorrect to unintentionally not destroy the object in
question on exit from the block.  For example a block which is holding
onto a Waldo which holds onto a Hand which is grabbing a Bert.  The
way the Bert is released is by destroying the Waldo (which destroys
the Hand, which releases the Bert).  It was a case like this that
originally motivated the MORTAL macro (back in the old "bogus" days).

It is interesting to note that "SPTR"s, "HeaperConstructor_Bomb"s (the
internal magic behind the CONSTRUCT macros), and "DSPTR"s are all
subclasses of StrongPtrVar which differ in their effective Bomb ACTION
behavior.  SPTRs have no action of their own.
"HeaperConstructor_Bomb"s have a bomb ACTION of (effectively)

 "{ if (SOURCE == BLASTING) { CHARGE->destroy(); } }" 

while (if I understand you correctly) DSPTR's effective ACTION would
be

 "{ CHARGE->destroy(); }".  

One can imagine a useful variety of DSPTRs whose ACTION is the former.
Then we could unify at least "HeaperConstructor_Bomb"s and DSPTRs, by
specifying that the variable in the first-argument of the CONSTRUCT
macro be one of these varieties of DSPTR, which would double as the
constructor bomb itself.  We would then end up with one less bomb on
the stack for (what is probably) a very common operation.

A significant moose with all this is: what do we write in Smalltalk so
that it both translates to DSPTRs appropriately (the easy part) and
means the same thing in Smalltalk (seems quite hard).  We should
probably wait on all this until we shoot that moose.


   ... And we get to add another pun to our collection.

   I hope that last doesn't influence any decisions.  B-)

Call me slow, but what's the pun?