Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Norman Hardy [mailto:norm@netcom.com]
> Sent: Saturday, July 29, 2000 5:35 PM
> To: Karp, Alan; 'Ken Kahn'; Mark S. Miller
> Cc: 'Dan Bornstein'; e-lang@eros-os.org
> Subject: RE: Split Capabilities: Making Capabilities Scale
> 
> 
> At 10:08 -0700 00/07/27, Karp, Alan wrote:
> >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.
> >
> >In your example, the programmer knows the interface to the garage, in
> >particular that it has an increment and a decrement method.  
> Could the
> >programmer have produced a correct garage object knowing 
> only about the
> >decrement method?  Of course not.  Could two programmers, 
> one knowing only
> >about the increment method and the other knowing only about 
> the decrement
> >method produce an entrance object and an exit object, 
> respectively, that
> >someone else could combine into a correct garage?  Perhaps, 
> but it is likely
> >that the entrance and exit codes would be based on invalid 
> assumptions.  For
> >example, the entrance object may assume that a garage that 
> becomes empty is
> >an error because its programmer sees no way for the count to 
> decrease.
> 
> I think that my example was too vague.
> I had intended that there were just two programs GS (Garage System) 
> and CCM (Car Counting Module). The GS program is responsible for 
> ensuring the correctness of the value hidden in the counter object. 
> The programmer of GS knows the entire semantics of the counter object 
> and also the garage layout. The programmer of CCM knows only that his 
> program will have access to a 0 argument procedure that his program 
> is to invoke once per observed car. CCM and perhaps GS define 
> instantiable objects and that several instances of CCM will be 
> created, most likely by GS. Upon startup GS creates one counter 
> object C. GS then creates an instance of CCM for each portal of the 
> garage. If a particular CCM controls an entrance its creation is 
> parameterized with the increment facet of C. Those controlling exits 
> get the the decrement facet of C.

In other words, the programmer of the CCM knows the legal state transitions
of the counter object.  I agree that I can reason about GS even if one CCM
only has the increment facet and the other the decrement facet.    

> 
> The remaining facet to learn the counter value is dispatched to the 
> sign driving program. Note that the sign driving program will not 
> come under suspicion if the count is in error.
> 
> Which programmer has insufficient information?

It is only when the programmer of the entrance (exit) module knows only
about the increment (decrement) facet that there is a problem.

> 
> >   At any rate, the routine doesn't have any
> >externally visible state, so it's not relevant to the 
> present discussion.
> 
> Agreed.
> -- 
> Norman Hardy  <http://cap-lore/>
> 

_________________________
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