[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

rewriting proxies' sending half



Date: Mon, 13 Aug 90 18:18:01 PDT
   From: xanadu!michael (Michael McClary)

   Though the hybrid approach can produce the smallest code in the proxy
   objects, it requires manual intervention if a new signature occurs.
   The approach I outlined is nearly as small, and requires no intervention.

The solution that Chris already has working on the receiving side
already requires manual intervention once for each new abstract
signature.  The alternative of running "varargs" backwards to build a
stack frame could be done, but would have to be rethought carefully
with each port (either to a new architecture or compiler).  Chris's
approach is completely portable, and (except for the above, admittedly
significant, problem) works at least as well.

   ... But this
   is a tool that is intended to be used by our developers.  ... 
   give them a mysterious link failure the first time they used
   a signature that we didn't.

Our first generation of developers will only be using it either 1) on
their own new classes, in which case they wouldn't be using either the
PROXY or the COPY features--only the PRIVATE feature for garbage
collection.  Or 2) to talk to our backend, in which case the entire
set of abstract signatures of PROXY methods is known by us statically
(therefore we can provide support statically).

   So unless we can come up with a way to generate all the signatures
   automatically, preferably with the existing tools or some upgrade of
   them, ...

I think this is quite straightforwardly doable.  I originally raised
the same objection you are raising, and Roger had a good outline for
how to do all this automatically (with a combination of "formic", a
shell script, "sort", and "uniq".  I suspect Chris rediscovered much
of it in order to measure the number of abstract signatures).  In
fact, it is sufficiently straightforward (IMHO) that we could do it
for first product if we had to.  Fortunately (by the above reasoning)
we don't have to.