Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Ralph Hartley [mailto:hartley@AIC.NRL.Navy.Mil]
> Sent: Friday, July 28, 2000 1:10 PM
> Cc: e-lang@eros-os.org
> Subject: Re: Split Capabilities: Making Capabilities Scale
> 
> 
> "Karp, Alan" wrote:
> > 
> > > Ralph Hartley wrote:
> > > Why not? A facet of an object, like an object itself only needs to
> > > fulfill its contract. The user of the facet (or object) 
> makes an error
> > > if he assumes anything about its behavior that is not 
> specified by the
> > > contract. Are you claiming that an object's contract must 
> COMPLETELY
> > > specify its behavior?
> > 
> > I don't believe that I can always write a correct program unless I
> > understand the contract of the object completely.
> 
> You need only understand the contract sufficiently. There are will
> always be contracts that you cannot understand completely. However
> that is not the point.

How do you know your understanding is sufficient?  I may not need to
understand the full contract to write a particular version of my code, but I
contend that I can't "reason" about the object without knowing its valid
state transitions.  I can certainly write a garage entrance object knowing
only about the increment behavior of the garage object, but can I "reason"
about the garage object to figure out what states are legal?  

If I use an object with a contract I don't fully understand, I run the risk
of my code breaking when that object is updated in a way that satisfies the
contract but that I didn't forsee.  This is what I mean about the ability to
"reason" about the object.

> 
> The point is that the contract of an object is NOT the same thing as
> its visible behavior. A contract is a conditional promise, it says
> that if some conditions are met some statement will be true. Any
> property or behavior of an object that is not implied by that
> statement is not constrained by the contract at all.

Agreed, but does changing the set of conditions constitute changing the
contract?  I contend that the answer is yes.  For example, if the condition
is that the garage is initially empty, then the garage exit object will know
something has gone wrong if the count ever goes negative.  However, if I
change the garage object to count the net number of cars per day, say by
initializing its count to zero each midnight, then the garage exit object
will erroneously report an error.  As far as I'm concerned, the contract was
changed.

> 
> I might contract to paint your house if you pay me $x. If you don't
> pay me I can do anything I want, I might even paint your house for
> fun.

Great!  I'll buy the paint.

> 
> Any behavior of an object that is not constrained by the contract is
> like an "undocumented feature", a program that relies on it may work,
> but it contains an ERROR.

Agreed.  I can reason about the object.  My argument, though, is with
behaviors that are constrained by the contract that the programmer doesn't
know about because all he has is a facet.  Since I can't reason about the
facet as an object (state+behavior), my program may contain an error simply
because there is a clause in the contract that doesn't appear in my facet.

> 
> > > For instance the contract for the "do" method might state "The do
> > > method changes the value of getX(). Immediately after its 
> execution
> > > the value of getX() is different than immediately before. Any side
> > > effects of changing this object (if any) are guaranteed to take
> > > place."
> > 
> > This definition is vacuous (For all I know, do() could be 
> taking the square
> > root.)
> 
> It is not vacuous, if I record the value of getX() call do() and check
> getX() again, and the value has not changed, I know the value changed
> at some other time. Also, if I know about side effects of changing the
> value, I know I can trigger them.

But I can't use the object for anything useful unless I know the state
transition that occurs when do() is invoked.  Is X incremented, decremented,
unchanged?  Is some arbitrary function applied to it?  I can't find out by
doing getX() - do() - getX() because someone else may have modified the
state between calls.

> 
> > 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.".  
> (I'm purposely
> > avoiding getX().)  If this is the definition of the object, 
> not just von
> > Braun's facet, we're done.  However, if someone else holds 
> a facet that can
> > increment the count of this object, the definition would 
> have to include
> > "There is also a method that increases the value of the 
> count."  Without
> > this information, von Braun might assume a failure to 
> launch was related to
> > an error in the behavior of the countdown object instead of 
> a launch delay
> > imposed by someone else increasing the count.
> 
> But he would be incorrect to assume so. What is not forbidden is
> permitted. He was never told that the count never increases so he was
> unjustified in believing that it would not.

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.

> 
> > > Given that contract there are some inferences one can 
> make about the
> > > behavior of the object. One can not however predict the 
> actual value.
> > > The contract also does not say that the value will not 
> change at other
> > > times.
> > 
> > Exactly why I said that von Braun expects the launch to 
> occur before the
> > 11th decrement; he understands that someone else may be 
> decrementing.  The
> > problem is that if von Braun only sees his decrement facet, 
> he has no way to
> > know that someone else might be incrementing.
> 
> But if he has not been told that there is no increment method he
> should not assume that there isn't.

See above.  Should he also assume that there's no sqrt() method?

>  
> > > The lack of complete specification may be there to give the
> > > implementor more freedom, or it may be put there for a reason.
> > 
> > The implementor is free to change anything that doesn't 
> affect the visible
> > effects of the object.  Changes to the implementation that 
> produce the same
> > result, changes that are not visible outside the object, 
> such as private
> > variables, and methods that don't change the visible state, 
> such as new
> > get() methods, are allowed.  Changes that are visible to 
> the outside, such
> > as adding an increment method, change the contract and can 
> break existing
> > code.
> 
> He is free to change the visible effects of the object too as long as
> the changes do not violate the contract.

Your statement is more precise.  I should have put it that way.

> 
> > 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.

> 
> Ralph Hartley
> 

_________________________
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