COPY / PROXY and the Translator

[Mark S. Miller <mark>]

Date: Mon, 23 Oct 89 00:40:45 PDT
   From: tribble (Eric Dean 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.  I'm concerned about the concreteness
of BazProxy, not of any RealBaz subclasses that the programmer
manually defines.  Does this clear it up?

      I agree.  If I understand stubble & formic correctly, there is no
      reason for all the copy variables to be gathered together in one COPY
      section instead of having several (Mr Hill?  Roland?  Do I have this
      right?). 

   I hope this works because the easy solution generates a COPY
   declaration for each variable.

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?