Split Capabilities: Making Capabilities Scale

Mark S. Miller markm@caplet.com
Wed, 09 Aug 2000 09:24:38 -0700


At 04:42 AM 8/9/00 , Jonathan S. Shapiro wrote:
> > 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.

I'll go ahead and make this claim, for particular cases of facets of a 
composite, whether thinning facets or not.  (Note that the incr/decr 
example used by much of this discussion has facets, but not thinning 
facets.)  Ralph's example is an excellent case of an adequate contract being 
stated -- for other programmers, not just for other programs -- of a 
decrement facet of a similar composite.  Probably in fact the programmers in 
this scenario would know of the existence of the other facets, and it is 
probably a good idea to run a shop such that they would know.  However, 
rather than preventing trouble (or, at least, in addition to preventing 
trouble), this extra knowledge also gets them into trouble:  

     It is harder to avoid counting on what you know than to avoid counting on 
     what you don't know.

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.

This pristine theory usually fails because there's rarely an articulated and 
explicit contract between provider and client.  Both then use partial shared 
knowledge (or model) of the implementation, combined with a shared sense of 
what properties are intentional vs accidental.  However, in this more 
typical scenario, it can still be good for the provider to hold back from 
the client information the client shouldn't count on, and for the same 
reason.  As Ralph's example demonstrates, the information that should be 
withheld may include knowledge of other facets.

Perhaps we need to clarify which programmer you mean by "the programmer" above.


         Cheers,
         --MarkM