Split Capabilities: Making Capabilities Scale

[Ralph Hartley]

Bill Frantz wrote:
> 
> At 09:24 AM 8/9/00 -0700, Mark S. Miller wrote:
> >Much of the point of a contract is to avoid stating what your clients aren't
> >supposed to count on.  The provider may then make future changes that
> >continue to satisfy his stated contract, and hope not to break too many of
> >his clients.
> 
> The best contracts are explicit about what the client can't count on.  For
> example, even if the directory lists always come out in sort order, if the
> designer wishes the flexibility to change that order, the contract should
> be written to specify that the order is not guaranteed.  Having to get that
> information implicitly leads to getting the information by experiment with
> an actual instance of a server implementing the contract.

That is why many real world contracts contain language like "This
contract is the whole of the agreement between the parties," which
means "anything not in this contract is something you can't count on."

Another example.

Suppose you are a real estate company with many houses, and I am a
painting contractor. Our contract might read:

  Over the next year I will paint one or more of your houses.
  Each house will be painted within one week of your request.
  You will pay me $1000 for each such house within one week
  after it has been painted. I will use professional quality
  paint, and the work will be of professional quality.
  This contract is the whole of the agreement between us.

Note that the contract says nothing about the color.

You have me paint 10 houses. I paint them all white. I paint 100 more
houses - all white. For the 111th house I don't have enough white
paint left, so I paint it blue. Should you be surprised? No.

Empirical observation, though tempting, is not a valid way of adding
terms to the contract.

Lets stretch the analogy a little further. You ask one of the workmen
who do the actual painting what color paint they use, this is
analogous to looking at the source code. He says they always paint
houses white. This also does not add a term to the contract.

The whole point of a formal contract is to make it perfectly clear
what is, and is not, promised. Of course it might be nice to spell out
everything that the parties should not assume, but this is in general
impossible. There are infinitely many things that you might assume.
There are almost as many things you might guess are always true by
empirical observation or looking at the source code. There is no way
to anticipate them all.

Of course it is possible to write a contract that specifies
everything. A software object could have the contract:

  This object behaves exactly like this code.

There are very good reasons for not doing that most of the time
(Though I have seen it done).

Ralph Hartley