Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Sunday, July 23, 2000 5:22 PM
> To: Karp, Alan
> Cc: 'Jonathan S. Shapiro'; e-lang@eros-os.org
> Subject: RE: Split Capabilities: Making Capabilities Scale
> 
> 
> At 05:22 PM 7/20/00 , Karp, Alan wrote:
> > > In E I'm not sure what "objects are cheaper than 
> > > capabilities" would mean.  
> > > Objects and capabilities are 1-for-1.
> > > 
> >
> >I thought that capabilities are handles for objects and each 
> represents a
> >facet of an object.  An interposer is a running piece of 
> code; a capability
> >is the handle used to access the interposer and the access 
> rights of the
> >facet.  
> 
> I think we have the same picture in mind, but are using 
> slightly different 
> labels.  I believe your usage may also correspond to Jonathan's in 
> describing EROS.  ("... capabilities conveying distinct 
> access rights to the 
> same object."  --p64 of 14Feb99 Draft of EROS Thesis)  I used 
> to use the 
> same labels I think you and Jonathan are using, but I found 
> there were some 
> fine points I couldn't make.  
> 
> We agree on "facet", and that the same object-state can be 
> seen through 
> multiple facets.  However, what's an "object"?  If we take 
> seriously the 
> conventional slogan that "An object is a combination of state 
> and behavior", 
> then the object-state shared by a set of facets is not an 
> object, it is only 
> state.  (It may in fact be an object at a lower 
> implementational level of 
> abstraction, but that would be another matter.
> 
> By this definition, only the facets are objects, since the 
> facet represents 
> the pairing of state (heap-allocated object state) and 
> behavior (vtable-like 
> method dispatch).  Only in what Jonathan calls a "thinning" 
> pattern, can the 
> behavior be seen in terms of "access rights", because only in 
> this pattern 
> is one vtable exactly a subset of another more powerful 
> vtable.  This is a 
> common faceting pattern, but not the only one.  For example:
> 
>      define incDecPair new(x) :any {
>          [define incr do { x += 1 },
>           define decr do { x -= 1 },
>           define getX() :any { x }]
>      }
> 
> returns three facets on shared state.  The first two both 
> respond to the 
> "do/0" message ("do" with 0 arguments).  But they each 
> respond to it with 
> different behaviors.  The first represents only the authority 
> to increment 
> x, and the second only the authority to decrement x.  To 
> someone who holds 
> one of these facets, they can exercise the authority they've 
> got, but they 
> can't tell which flavor of authority that is.
> 

Ouch!  What does this definition have to say about encapsulation?  If my
facet has state x and decrement behavior, another facet having increment
behavior can appear to break encapsulation on my object.  In practice, we
break encapsulation all the time for convenience and performance reasons ala
Perl and Python.  However, the purer the object model, the easier I find it
to reason about what's going on.

_________________________
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