Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Ralph Hartley [mailto:hartley@AIC.NRL.Navy.Mil]
> Sent: Friday, July 28, 2000 6:06 AM
> To: e-lang@eros-os.org
> Subject: Re: Split Capabilities: Making Capabilities Scale
> 
> 
> > There seems to be some confusion as to what I'm talking 
> about.  There is an
> > object O with some interface.  There are facets of O that represent
> > thinnings of that interface.  I agree there is no problem 
> if the programmer
> > of some other object knows the interface to O.  If the 
> programmer only knows
> > a facet of O, he may not be able to correctly code his object.
> 
> 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.  As I said, the person
coding the garage entrance object may assume it's an error if a non-empty
garage becomes empty.  In fact, given knowledge only of the facet and not
the object, and thinking of the facet as an object, that's exactly the kind
of boundary checking that good programmers do.

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

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

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

> 
> Consider a partial information game. Each player may not know all the
> effects of his moves. He may also not know how many other players
> there are or what their legal moves are. Given some information about
> these things such games can be quite complex, even with very simple
> rules.

I have played such games.  (One of my favorites is for little kids.  In
"Gertrude's Secrets" part of the game is figuring out the object of the
game.  It's amazing how fast a 4 year old gets it.)  The point of the game,
though, and the best way to win is to figure out the missing information and
then develop a winning strategy.  That's why good Kriegspiel players (chess
where you can't see your opponent's pieces) always bring out their queens
early, a bad strategy in real chess.

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.

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