Split Capabilities: Making Capabilities Scale

[Karp, Alan]

I agree.  To me the source code is useful because it describes the object's
behavior, i.e., its valid state transitions.  The documentation to the
object is supposed to do the same thing.  That's all I need to reason about
the object.  Misunderstandings, whether due to inadequate documentation or
my failure to understand it or the source code is a source of bugs that we
must live with in the real world.  I am indeed arguing philosophically, but
I recognize that I must tolerate opaque behavior caused by such
misunderstandings.

The fact that a facet purposely hides part of the object's state transition
diagram from me is the reason I don't equate facet with object.  I don't
mind coding within the restrictions imposed by the facet; I just often need
more information about the behavior of the object.  Even in the real world,
programmers should be given access to the behavior of the object behind 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: Jonathan S. Shapiro [mailto:shap@eros-os.org]
> Sent: Friday, July 28, 2000 4:25 PM
> To: Karp, Alan; 'Ralph Hartley'
> Cc: e-lang@eros-os.org
> Subject: Re: Split Capabilities: Making Capabilities Scale
> 
> 
> > > 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?
> 
> Observation and testing.
> 
> 
> It is simply a fact that there is opaque behavior in the 
> world. It's called
> binary code. Taking a philosophical position against this is 
> reasonable, but
> not very interesting in practice. It seems to me that Alan is 
> taking roughly
> this position.
> 
> What you know about binary-implemented objects is whatever 
> the development
> team put in the manual. Note that this is an *allegation* 
> about the behavior
> of the code, not a truth assertion. It is an allegation in 
> the same way that
> the procedure name decrement() is an allegation about what 
> the procedure
> does. There is no necessary correlation between the name of 
> *any* procedure
> and it's actual behavior. At a minimum, the code probably has bugs.
> 
> So the real debate here is not about facets, it's about 
> opacity. In my view,
> opacity is simply a fact of life.
> 
> Facets are certainly not a problem (even to Alan) if the 
> source code is
> available. The contract in this case is fully exposed.
> 
> The purpose of protected facets, then, is to enforce 
> statically a runtime
> restriction on which parts of the entity's behavior a 
> particular client can
> invoke. It is a discipline imposed on the program at runtime. 
> It is *not* a
> restriction on the programmer.
> 
> The only restrictiona on the programmer in this model are 
> imposed by the
> inadequacy of documentation and/or the inadequacy of their 
> understanding of
> the source code (if any).
> 
> Last comment: source code is not a panacea. Given enough 
> lines, you cease to
> have time to read them, and you are reduced in practice back 
> to opaque code
> and allegations about what it does  -- er, um, I mean developer
> documentation.
> 
> 
> shap
>