Split Capabilities: Making Capabilities Scale
Jonathan S. Shapiro
Wed, 9 Aug 2000 07:42:12 -0400
> 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
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.