rewriting proxies' sending half

[Mark S. Miller <vlad!mark>]

I think your scheme is quite good, and very much along the lines that
we had in mind.  However, here's some nits and alternatives.

   Date: Sat, 11 Aug 90 16:58:56 PDT
   From: xanadu!evilotto!hibbert (Chris Hibbert)

   ...

   to something more like:

       SP2_Rational pop () {
	   SP2_Rational result;
	   SPTR(CommXcvr) trans = commHandler->newCommXcvr ();
	   result = CAST(Rational,
			 trans->handleSend(cat_Rational,
					   cat_Calc, objectNumber, "pop2"));
	   CommXcvr * temp = trans;
	   delete temp;
	   return result
       }


Minor point:  The lines

	   CommXcvr * temp = trans;
	   delete temp;

should be replaced with

	   trans->destroy();

(in both the old code and the new).  "delete" should be considered a
low level oddity in X++, much as "new" is now considered.  (I should
send out a mail message soon giving some thoughts on "delete" vs
"destroy" vs "reclaim" vs "p->Heaper::~Heaper();".)

   The handleSend method is pretty simple.  It uses VARARGS, and knows
   that the first few arguments describe the return value type, receiver
   type, receiver object number, and the message to be sent.  The rest of
   the arguments describe, in pairs, each of the arguments and its type.

It occurs to me that since you've now got the message-descriptor
objects working on the receiving side, that they are just what you
want to coordinate the sending side as well.  They can even do so in a
type safe / not-VARARGS manner as well.  Instead of the above code, we
have stubble generate:

       SP2_Rational pop () {
	   return CAST(Rational,
		       theRationalPop_Handler->handleSend (commHandler,
							   objectNumber /*
							   input args,
							   output args */);
       }

(I didn't bother to check what our actual name mangling conventions
are for message description classes and instances.  So please bear
with me.)  The arguments to the call to "handleSend" above would
exactly parallel the parameters of pop, except that there would be the
commHandler & object number arguments in addition, and there might
need to be some funky casting of output arguments (should we decide to
continue supporting them).

The Message handler class which "theRationalPop_Handler" is an
instance of defines it's own (non- polymorphic) "handleSend" method
which the above call is type compatable with (except possibly for
output args), as the method has the corresponding abstract signature:

SPTR(Heaper) Heaper_void_Handler::handleSend (CommHandler * comm,
					      IntegerVar objectNumber)
{
	SPTR(Heaper) result;
	SPTR(CommXcvr) trans = commHandler->newCommXcvr ();

	/* if there were input arguments, you could do a run-time, */
	/*  data-driven type check of them here */

	trans->hello (myReceiverCategory, objectNumber, myMessageName);
	trans->over ();
	trans->startGetResults ();
	result = trans->receive (myResultCategory));
	trans->endGetResults ();
	trans->goodbye ();
	trans->destroy ();
	return result;
}

Paralleling the current stubble generated code, but shared among all
proxy methods with the same abstract signature.

How's that look?