Split Capabilities: Making Capabilities Scale

[Ralph Hartley]

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

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.

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.

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.

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

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

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

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

Ralph Hartley