Split Capabilities: Making Capabilities Scale

[Jonathan S. Shapiro]

> I guess the real difference we have is what constitutes a contract.  I
> contend that the part of the contract represented by any thinning facet is
> inadequate.

I don't think I ever claimed that the thinned facet provided adequate
knowledge or represented an adequate statement of contract for the
programmer. I still think that you are failing to differentiate what the
programmer knows from what the program knows in your argument.

> The programmer needs to know the full contract represented by
> the legal state changes of the object.

Here we disagree. First, I don't know how (in principle) to write this down.
Second, if presented with such detail I suspect that it would be so
overwhelming as to provide minimal value.

> That means that changing the
> behavior, such as adding an increment method after von Braun's countdown
> object was written, must be done by subclassing.

I think this is mistaken. Subclasses can violate superclass contracts in all
the real OO languages I know about. In the final analysis, I think that only
full configuration management of the running image suffices.

The problem in practice isn't really that the contract has changed. The
problem is that one programmer can alter a piece of another's application.
If there were a place to stand to do acceptance testing it would be okay to
let the contracts change *with consent*. Configuration tracking potentially
provides such a place to stand.

shap