COPY / PROXY and the Translator

[Eric Dean Tribble <tribble>]

Non-PROXY messages in a proxified class should also
	       not be DEFERRED, since the stubble generated Proxy subclass will have
	       to be a concrete class (XLint doesn't need to check for this, the
	       compiler will).

      Presumably member functions in the PROXY forward the message over the
      wire.  This is completely automatically generated and shouldn't care
      whether a body for the real object was defined.  Concrete subclasses
      could then be defined which could be exported to another machine only
      as the parent type.

   I don't understand your paragraph at all.  Perhaps the following will
   clear up our misunderstanding:  If "Baz" is a class with a "PROXY:"
   section, then stubble will automatically generate a subclass of it
   called "BazProxy".  BazProxy must be a concrete class, an the
   RPCTransceiver code will instantiate it when any object which is a
   kind of Baz is passed by proxy.

 BazProxy can be made concrete even if Baz is not.  Let's take a
sample method in the PROXY section:

PROXY:
   Object * getValue(Position * key) DEFERRED_FUNC;

Stubble can still generate the code that forwards the message even
though RealBaz doesn't implement the message.  

Object * BazProxy::getValue(Position * key) {
   /* transmit the message across the wire. */
   wire ->transmitMessage('getValue', 1, key);
   /* or whatever the stubble magic is */
}

I might be completely misunderstanding the mechanism under stubble.

   I'm concerned about the concreteness
   of BazProxy, not of any RealBaz subclasses that the programmer
   manually defines.  Does this clear it up?

Obviously the user couldn't actually instantiate a RealBaz.  The user
could transmit an instance of a concrete subclass of Baz across the
network. 

   OOPS!!!  I'm quite sorry.  Formic & Stubble will have no trouble with
   multiple PROXY and COPY sections, but X++ will.  Because of what the
   COPY & PROXY macros expand to, the compiler will barf if these appear
   more than once in a given class declaration.

   This is unfortunate because, as I'd argued before, the flexibility
   would be good.  However, when I think about fixing this problem I'm
   rather inclined to put up with the problem instead.  How bad is fixing
   the translator to consolidate these?

UGH! Doable, but a pain in the @#$.  It's probably much easier for
COPY instance variable than methods.  Let me sleep on it (actually
let's let hugh think about it).

dean