Split Capabilities: Making Capabilities Scale

[Karp, Alan]

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.  The programmer needs to know the full contract represented by
the legal state changes of the object.  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.  von Braun can then
continue to instantiate his countDown objects while someone else can
instantiate countUpDown objects.

Here's where I argue against my own case.  The ISA relation can cause
problems.  If someone passes von Braun's program a countUpDown object
created as a subclass of countDown, this object ISA countDown object and may
have behavior the program von Braun wrote did not anticipate.  The fact that
languages don't let von Braun know that the ISA relationship is by
inheritance means that the real world has no problem dealing with the
behavior I'm worried about.  The analogy is saying that the object ISA
instance of the facet.

_________________________
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


> -----Original Message-----
> From: Ralph Hartley [mailto:hartley@AIC.NRL.Navy.Mil]
> Sent: Monday, July 31, 2000 11:17 AM
> Cc: e-lang@eros-os.org
> Subject: Re: Split Capabilities: Making Capabilities Scale
> 
> 
> > > > and would not let von Braun use the object to count 
> down to launch.
> > > > He could if the definition was "The do method decreases the
> > > > value of the
> > > > count by 1.  Launch occurs when the count reaches 0.".
> 
> If I were on Braun I would never accept that as a contract for a
> countdown object. He needs at least :
> 
> The count is a non-negative integer that is initially ten.
> When on Braun uses his decrement message the count decreases by
>   at most one.
> The count will never decrease at any other time.
> If the count is less than ten and the count has
>   decreased in the last second the count will
>   not decrease.
> Whenever the count decreases to a value less than ten
>   the new value is broadcast on the PA system (so that
>   everyone can hear).
> Launch may occur when the count reaches 0.
> 
> This contract does not describe all of the countdown object's state
> transitions. It does not mention the possibility that the count might
> increase at all. One cannot do complete reasoning about it. But one
> can make some inferences:
> 
> No one but on Braun can trigger a launch.
> No one will ever be surprised by a launch, everyone will
>   have at least ten seconds notice.
> 
> Suppose on Braun's programmer has a copy of the source code for the
> countdown object and he notices that the count can never increase. Can
> he use this fact? No, it would be an error to do so. Someone might
> notice after van Braun was written that the range safety officer needs
> to be able to cancel a launch, and that many other people need to be
> able to delay it. It is legal to rewrite the counter object so that
> the countdown can be stopped or incremented, since such an
> implementation is not forbidden by the contract.
> 
> Nor should the fact that in all the test runs launch occurs after
> exactly ten calls to decrement cause on Braun to be surprised on the
> day of the launch when launch happens after 127 decrements. Nor should
> anyone be surprised when launch occurs 15 seconds after the PA system
> announces "count = 30" (the count might not have really been 30 or on
> Braun may have decremented 20 times in five seconds then once per
> second for 10 seconds). But if launch occurs without the numbers 1-9
> being announced then the countdown object is broken.
> 
> > That's just great.  Now von Braun doesn't know what might 
> happen.  If the
> > count can start negative, he can't use it for his launches. 
>  How many other
> > possibilities must he worry about?  Can it decrement by 7 
> at random?  Can
> > the value turn into a floating point number?  A string?   
> Why not?  Nobody
> > said it couldn't happen.  I don't think I'd like writing 
> programs under such
> > conditions.
> 
> You (I think it was you, I might have lost track) wrote the contract
> not me. To prove a system correct (which is what I assume you would
> like to do by "reasoning about objects", you must prove that each
> object (or facet) fulfills its contract assuming all objects or facets
> it uses fulfill theirs, and that the system meets its specification if
> all its objects fulfill their contracts.
> 
> > > > Of course, this is all off the point, which is to answer
> > > the following
> > > > question.  If object is state plus (externally visible)
> > > behavior, can I
> > > > reason about a facet as an object?  My contention is that I
> > > can't because
> > > > I'm missing information about the legal state transitions.
> > >
> > > You can still reason about an object who's contract does not
> > > completely determine its visible behavior. The results of your
> > > reasoning will just be weaker, that's all. People reason 
> about things
> > > without complete descriptions all the time (literally).
> > 
> > Yes, I can reason about the object, but incompletely.  It 
> is exactly the
> > incompleteness of the view of the object presented by a 
> facet that leads me
> > to believe that I can't reason about the facet as an 
> object.  It is this
> > imprecision that leads to software failures (people 
> failures, too).  Failing
> > to specify my units may cause my spacecraft to miss Mars.  
> Relying on a
> > poorly worded contract may lead to a law suit.
> 
> It is far more important that your reasoning be sound than that it be
> complete. In fact, it is generally impossible for reasoning to be both
> (Godel and all that). It is not imprecision that causes errors, it is
> unjustified assumptions. Assuming that a counter can never increase,
> just because you have not been told that it can, or because it never
> has, or because examination of the internal code of an object (unless
> the objects contract specifies that it will always be implemented by
> that code) shows that it never does, is an example.
> 
> A facet is simply an object who's implementation is provided by
> another object. Its contract will in general be different from that of
> the underlying object. In the case of a thinning, its contract will
> generally be weaker, in the sense that the underlying object can
> always substitute for the facet, but not the other way around.
> 
> Note that under this definition, an object and a thinning of the
> object may implement exactly the same methods using exactly the same
> code, and still be different if they promise different contracts. For
> instance a countdown object could be correctly implemented as a facet
> of a non-increasing countdown object.
> 
> Ralph Hartley
>