Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Jonathan S. Shapiro [mailto:shap@eros-os.org]
> Sent: Sunday, July 30, 2000 4:58 AM
> To: Mark S. Miller
> Cc: Karp, Alan; 'Ralph Hartley'; e-lang@eros-os.org
> Subject: Re: Split Capabilities: Making Capabilities Scale
> 
> 
> A further quibble.
> 
> There is a flaw in the entire line of argument, which is that 
> it assumes
> code to be static. In practice, we introduce new printer 
> widgets into the
> world after applications ship, and the app developer clearly 
> didn't get to
> inspect these new widgets. In this context, the facet is the syntactic
> element off of which we humans hang the interface contract.

And we get into trouble.  I recently locked up a printer because the new
printer has a different contract than the old one.  It allows me to request
duplex printing of transparencies even though the printer itself knows
better.  Installing the proper driver fixed the problem even though the
instructions said that I didn't have to.  My point is that seemingly
innocuous changes in the visible state of the object can affect some
programs, even if they are not responsible for those state changes.

> 
> Part of the subtext of the facet objection has been about the 
> difference
> between what can be said in the syntax and what the contract 
> actually is. In
> reality, I don't think we are ever going to get to a perfect contract
> specification language. More to the point, if we had it I 
> believe that it
> would be too cumbersome to actually use it.

Would not the object's state transition diagram suffice?

> 
> shap
> 

_________________________
Alan Karp
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278