I'm afraid I was too elliptical in my first attempt to describe this
problem. Here's my next attempt:
Suppose that we have a class common.A with encode() and decode()
methods. In 10.1 and 10.2, these methods have identical signatures but
implementations which differ so that the 10.1 decode() does not invert
the 10.2 encode().
Now let's mix a 10.1 client with a 10.2 server in the same VM.
If we don't clone the code, then encode() and decode() will invert one
another regardless of how we wire 10.1 and 10.2 jars together in the
classpath.
However, suppose we clone the code to arrive at client.common.A and
server.common.A. Suppose further that the client jar, reasonably, does
not contain server classes and vice versa. In this case, the client's
decode() will not invert the server's encode(). Somehow, we need to
detect this incompatibility.
The point I am trying to make is this: It seemed to me that code cloning
was put forward as an alternative to the compatiblity checking in
David's first proposal. I don't think cloning solves this problem. It
merely pushes the problem around a bit. We still need run-time
compatibility checking.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
I would like to add a few comments to this very useful discussion:
[snip]
(2) A possible solution was raised: instead of cloning the code in the
source tree, clone it during the build process. I have written similar
kinds of ant-based code pre-processors and can give some advice if we
adopt this approach. Done right, it's a pleasant afternoon's work.
However, I have reservations about this approach. It seems to me that it
subverts the meaning of "common" code. To me "common" means "behaves the
same way." It's not just a matter of preserving APIs that the compiler
can check. It comes down to actually doing the same thing internally. As
an example, consider a pair of encoding/decoding methods. You want the
internal encoding/decoding logic to be the same everywhere. I don't
think that build-time cloning saves us from the problem of having to do
a run-time compatibility check.
Not sure what point you are making here, how does copying the code into
different packages change its behaviour?
With what ever approach, if the client is at version X and the
engine/network server at version Y then by definition the common code
will be different. Could be the same api, but maybe bug fixes in Y that
don't exist in X.
Dan.
