COPY / PROXY and the Translator

[Mark S. Miller <mark>]

Date: Wed, 25 Oct 89 23:31:26 PDT
   From: tribble (Eric Dean Tribble)

		  #1, MarkM:
		  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).

	 #2, Dean:
	 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.

      #3, MarkM:
      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.

   #4, Dean:
   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.  

Of course all messages defined in a PROXY section should be DEFERRED.
I am also unconcerned with whether RealBaz implements the message.
Note that in #1, I am specifically referring to messages defined in
Baz that are *not* defined in a PROXY section.  Presumably the meaning
of defining these outside the PROXY section is that the programmer is
instructing stubble *not* to generate forwarding code (or any other
code) for it.  Since BazProxy must be concrete, it needs some
definition for any message declared DEFERRED in Baz.  Where should
this come from?  If this doesn't make sense, please give me a call.

This does suggest an interesting extension to stubble: for the above
currently-defined-to-be-incorrect case (a DEFERRED message in a
proxified class outside a PROXY section), stubble could generate a
non-DEFERRED declaration for it in BazProxy and provide no definition.
This would require the programmer to define how BazProxy responds to
this message.  It would be a SELF_PROXY kind of ability: i.e., it
would provide an ability whose relationship to PROXY is analogous to
the relationship of SELF_COPY to COPY.  Both to emphasize the analogy,
and to make the programmers intentions clearer to readers of his code,
I think such messages should only appear in a "SELF_PROXY:" section.

As this ability would be a strictly upwards compatable change that is
currently unneeded, I propose we remember it but don't do anything yet
towards implementing it.  It may prove useful when we want to write
proxies that do local caching.