Split Capabilities: Making Capabilities Scale

[Karp, Alan]

The thing that sold me on objects was encapsulation.  If I understand the
visible state and behavior (legal state changes) of an object, I know
everything I need to use the object properly.  If my use of the object
affects objects that I don't use, I don't need to know about the effects.
Hence, unless the correctness of my code depends on the price of beverages
in the Orient, it doesn't concern me.  If it does have such a dependence, I
must be using some part of the state of the Oolong tea object or some object
it affects, in which case I'll need to know the state and behavior of that
object.  The analysis is on an object by object basis and only includes
those objects with behavior that affects my program.

That's the problem I have with thinking of facets as objects.  There are
state transitions in the interface to a single object that affect my program
that I'm not aware of because they don't appear in my facet.  I'm not saying
that I need to know all possible ways that the count can be incremented; I
only need to know that there is a method that increments the count.

Traditionally, we've used interfaces to describe the legal state changes.
These are accompanied by human readable descriptions (documentation), but
the only reliable description is the code itself, as you state.  I'm puzzled
by your statement that you don't feel that a formal description of the
object's behavior is possible.  Can't I present a state transition diagram,
at least in principle?  Of course, analyzing the conditions for a transition
may involve other objects, but the worst case would be the union of the
diagrams of the finite set of objects involved in the operation.  This set
may be impractically large, but I believe it's a theoretical possiblity.

E-speak takes a simplistic approach to describing behavior; it delivers a
Java interface file.  It is assumed that the human programmer understands
the effect on the state of the object of each method in the interface.  The
e-speak Service Framework Specification goes further in that it provides
this information in XML, solving the syntax problem, as well as providing
information on the conversations (order of messages or protocol) that the
object supports.  However, at the end of the day, correct use of the object
depends on human understanding.

_________________________
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: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Wednesday, July 26, 2000 5:26 PM
> To: Karp, Alan
> Cc: 'Eric Messick'; 'Ken Kahn'; Norman Hardy; Karp, Alan; 'Dan
> Bornstein'; e-lang@eros-os.org
> Subject: RE: Split Capabilities: Making Capabilities Scale
> 
> 
> At 03:03 PM 7/26/00 , Karp, Alan wrote:
> > > From: Eric Messick [mailto:eric@syzygy.com]
> > > ... the person who
> > > programmed "von Braun" *does* know about the existence of the
> > > increment operation and has coded "von Braun" 
> appropriately (what ever
> > > that might mean).
> >
> >That's what I was hoping that MarkM would say, that the 
> programmer of the
> >von Braun object knew about behaviors not represented by 
> facets held by the
> >programmer who delegated them to von Braun.  I took his statement "No
> >automatic awareness provided." to mean that this was not the 
> case.  Without
> >such knowledge, the programmer may not be able to code a 
> correct von Braun
> >object. ...
> 
> At 02:33 PM 7/26/00 , Ken Kahn wrote:
> >... But in an open system
> >where programs communicate over trust boundaries there are inherent
> >limitations about how much you can reason about the system 
> behavior. ...
> 
> At 03:13 PM 7/26/00 , Karp, Alan wrote:
> > > I suspect there are some unspoken assumptions about the 
> > > overall context in
> > > this discussion of facets. Who is hiding side effects from who?
> >
> >No one.  Whoever decides that I get to see only a facet that 
> reveals less
> >than the full behavior of the object is hiding from me state 
> transitions
> >that I interpret as side effects.
> 
> Milton Friedman says:
>  > No one knows how to make a pencil.
> 
> I'm with Ken, and I'm not saying what you hoped I would say.  
> (I also doubt 
> Eric is actually saying what you hoped I would say, but I'll 
> let him handle 
> that.)  As a programmer, when I program object A to use 
> services provided by 
> object B, I usually do so without being aware of the 
> transitive closure of the 
> side effects that will result from my interactions with B. 
> Also, I often do 
> so without being aware of the transitive closure of side 
> effects from others 
> on B that may effect the answers I get from B. However, to 
> the extent that 
> B's interface contract is documented, I can program A 
> correctly by only 
> relying on documented properties of B. As long as A discharges its 
> contractual obligations while only counting on the services 
> it uses (B) to 
> discharge their obligations, then A is correctly coded, even 
> if it's coded 
> in ignorance of B's transitive side effects. (This 
> description assumes that 
> A may correctly rely on B to do what it is supposed to.  In a system 
> supporting mutual suspicion, this is often not the case, but that's a 
> separately analyzable matter.)
> 
> To use one of your favorite examples -- printing a page on a 
> printer -- 
> probably no one ever has had a complete account of the 
> transitive side 
> effects of this partly physical action.  If the printer runs 
> out of paper, 
> it may light an alarm causing someone to refill it and order 
> more paper, 
> causing a P.O. to be issued to a paper company, causing the 
> paper company's 
> EJB inventory system to crash.  The transitive closure of my 
> effects on the 
> price of paper effect the entire economy. Does this prevent 
> anyone from 
> printing on a printer correctly?  No.  As someone issuing a 
> print command, I 
> don't and shouldn't care whether the paper company's EJB 
> inventory system 
> works or whether the price of paper effects the price of tea in China.
> 
> I suspect that somehow we are arguing terminology rather than 
> substance 
> again, as it's hard to believe that the above description is 
> not equally 
> true of the E-speaks.
> 
> Ironically, some of the systems I have in mind -- KeyKOS, 
> EROS, Joule, and 
> E -- are almost unique in the world at providing A the ability to 
> insist on constraints on the transitive side effects of 
> objects it uses -- via 
> confinement.  For an observably confined B, A can indeed know 
> where the 
> transitive closure of side effects stops (modulo wall 
> banging).  But this is 
> and should be a special arrangement.
> 
> At 03:13 PM 7/26/00 , Karp, Alan wrote:
> >We have a similar problem in e-speak which we resolved by 
> providing the full
> >interface on request if authorized.  I recently decided that 
> all that's
> >really needed is a formal description of behavior.  Of 
> course, I don't know
> >how to write such a description, but that's OK.  Smart 
> people can figure it
> >out.
> 
> If you mean a machine understandable description, no they 
> can't.  A lot of 
> smart people have tried and failed.  The only complete 
> description *in 
> general* of the behavior of an object is the code (and state) 
> implementing 
> this behavior, as well as the transitive closure of other 
> objects that may 
> effect or be effected by this object.  Even this would not tell the 
> programmer of a client of the object which properties of this 
> behavior were 
> intended vs incidental.  Without this distinction it's 
> impossible to write a 
> correct client.  
> 
> Actual practice is that interface contracts are often 
> human-only-understandable decorations on interface types.  
> Rarely is the 
> entire contract even spelled out in natural language.  Most 
> of it is usually 
> in the folklore in the community surrounding the use of the 
> interface.  I'm 
> not advocating this, just observing.  I also don't imagine 
> that creating a 
> new platform (any of ours) will do much to change this practice.
> 
> So if you don't know how to write such a description, what 
> did you provide 
> on request?  Whatever that is, how is it different in kind 
> from an alleged 
> interface type?  How may A's (or von Braun's) programmer use this 
> description to know whether the side effects include Chinese 
> tea prices?
> 
> 
>          Cheers,
>          --MarkM
>