COPY / PROXY and the Translator

[Mark S. Miller <mark>]

Date: Sat, 21 Oct 89 13:27:31 PDT
   From: heh (Hugh Hoover)

     COPY and PROXY are properties of the instance variables.  A single class
   may have COPY instance variables, (meaning they are copied over the wire
   when the object is sent over FEBE) or PROXY variables (in which case, only
   an identifier of the real object on the end doing the sending is sent).

No.  COPY (and SELF_COPY) is an attribute of instance variable
declarations in a class declaration, and an attribute of a class.
PROXY is an attribute of method declarations in a class, and an
attribute of a class.  

A class may have a PROXY section (which may be empty) in which are
contained DEFERRED method declarations of messages to be sent by the
proxy object to the real object.  If a class has a PROXY section
(whether empty or not), we say it is a Proxified class (sorry for the
terminology, suggestions are solicited).  A Proxified class is itself
necessarily deferred.  It will have one subclass (which is
automatically generated by stubble) which is the Proxy class.  All
messages which are delared in a PROXY: section and sent to a Proxy
object will be forwarded by that proxy across the wire to the real
object (which must be an instance of some other subclass of the
Proxified class).  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).  When an object that is an instance of a subclass of a
proxified class is to be passed over the wire, instead the
corresponding proxy class is sent which knows to forward messages to
the original, which doesn't move.  Why do we allow proxified classes
with empty PROXY sections?  Because for these, eq-ness identity is
automatically maintained--if they are passed multiple times, the same
remote proxy is used, instead of a new one being created each time.

A class may have a COPY section (which may be empty) in which are
contained instance variable declarations, and an optional 
"void restart()" method declaration.  Such a class may evertually be
deferred or concrete.  When one of these is passed over the wire, it
is passed "by COPY", meaning that a new object is created remotely of
the same class as the original, and the instance variables in the COPY
section of the original are passed in order to initialize the
corresponding instance variables of the remote copy.  If the COPY
section does declare the restart method, then this method is called as
the last construction action of the remote copy.  This is typically
used to initialize instance variables that are not in the COPY
section.  Why do we allow an empty COPY section?  Because sometimes
the fact that we have an object of a given class is all the state we
happen to need (as happens for example with several kinds of UnaryFn
objects).

It is (will be) possible for a class to have both a COPY and a PROXY
section.  This will typically happen when the class also has some
non-PROXY methods.  For example:

CLASS(Zorp,Heaper) {
  PROXY:
    virtual void zip ()		DEFERRED_SUBR;
  public:
    LEAF IntegerVar zap ()
      {
	  this->zip();
	  return i;
      }
  COPY:
    IntegerVar i;
};

Stubble will automatically generate ZorpProxy, which will inherit the
"zap" behavior and the "i" state variable from Zorp.  Assuming that a
real Zorp class (with an actual "zip" behavior) is defined by the user
as class RealZorp, then it also has an "i" state (as well as possibly
other state defined in "RealZorp").  When an instance of a RealZorp is
passed, this is (will be) done by creating a remote ZorpProxy which is
constructed with a copy of the original's "i" state.  When someone
sends the "zap()" message to this remote proxy, the zap message
executes locally (on the proxy), using the local copy of "i", and
invoking the zip method, which itself gets forwarded over the wire.  I
say "(will be)" above because this mixing of COPY and PROXY is not yet
supported by stubble.  Neither is an deferred COPY class.

     Actually a class can have any mix, some COPY, some PROXY, and some neither
   (cache variables are good examples of what falls into the latter).  If a class
   does not have any COPY or PROXY variables, it can only communicate with 
   message sends - no state goes across the wire.

I don't understand how you arrived at this.  Perhaps you think that if
an instance variable is declared PROXY, then the object it points to
is passed by proxy?  If so, then this is simply wrong.  Whether an
object is passed by PROXY, COPY, a mix, or not passable is a property
of the class that the object is an instance of, not a property of an
instance variable used to refer to the object.  If a class is declared
neither PROXY nor COPY, and none of its superclasses is declared
PROXY, then it cannot be passed, and communication over the wire
cannot be in terms of it.

     OK, now that we have the basic defn's down, we can get onto the real prob.
   In your response, you indicated that it can be included in the variable type.
   That strikes me as a reasonable answer, but do we solve it with an attribute
   message (like {Table copy}) or do we add another setup like inst var type?
   I guess the former is adequate, although it makes translation a bit harder.

I don't know the answer, but it seems to me that PROXY should be based
on message category (as are public, etc...), and that COPY could
(should?) be attatched to instance variable type.  A proxified class
with no PROXY messages would be fine, because you can have a method
category with no occupants in Smalltalk (is this right?).  A COPY
class with no copy instance variables is more tricky.  As is the
declaration of restart.  Both could be handled by having another
method category which is either empty or contained the void restart()
method.  A class would then be a copy class if either it had a COPY
method category of any COPY variables.

     Where abouts in the translator is it appropriate to make those changes?  It's
   best (for readability) if the variables get grouped according to COPY, PROXY
   or normal before being printed.
   --Hugh

I have no idea (of course), but I hope this clears things up.