Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Monday, July 24, 2000 9:07 PM
> To: Karp, Alan
> Cc: 'Jonathan S. Shapiro'; e-lang@eros-os.org
> Subject: RE: Split Capabilities: Making Capabilities Scale
> 
> 
> At 02:58 PM 7/24/00 , Karp, Alan wrote:
> >Ahh, so that's the difference.  I was assuming that, as a 
> holder of the
> >decrement capability, I see an object that can only be 
> decremented.  In this
> >view, any increment is a side effect outside the object 
> model.  You are
> >saying that a holder of any of the foreseen facets is 
> automatically aware of
> >all the other foreseen facets, or at least those with 
> visible effects.
> >Thus, any action appearing in a foreseen facet is within the 
> object model.
> 
> No automatic awareness provided.  Also, in both examples, the 
> only thing 
> the holder of the decrement facet needs to know is that he can send a 
> "do/0" message to the object.  Nothing in this code implies 
> that the holder 
> of such a facet is able to determine that it performs a 
> decrement.  Were 
> this done is a Java-like statically typed language, both 
> increment and 
> decrement facets would be seen as being of type
> 
>      public interface {
>          void do();
>      }
> 
> with no further type information available.  
> 

Seems like an odd programming model where I say "do your thing whatever that
may be".  What would Werner von Braun say during a countdown, do() or
decrement()?  What would he say if he saw the count increase as he tried to
count down?

The conventional view of object is state + behavior.  I can't consider a
facet an object because there are behaviors affecting state that are
invisible to the facet.  I can consider an object to be state plus the union
of the behaviors of all the facets.

> 
> >This point raises an interesting question.  Knowing that an 
> operation is
> >possible makes a certain class of attacks possible.  Hence, 
> we want to
> >institute a policy of least information.  On the other hand, 
> it's not nice
> >to surprise your programmers, so we also want a policy of least
> >astonishment.  These policies are often in conflict, and 
> care is needed in
> >deciding which one to honor.
> 
> Of course, by changing the code, the provider of these facets 
> can provide to 
> the holder more information about what she alleges these facets do.  
> However, these claims are only claims.  KeyKOS wisely called 
> the query to 
> get an object's interface description "allegedType".

Granted they are claims, but the behavior has to obey the rules.  If it
doesn't, I can't use the object with any assurance.  The whole idea of OO is
to hide the implementation behind the interface.  Change the implementation
all you like, but if I think you're decrementing, and you're doing something
else, I've got a broken application.

> 
> 
>          Cheers,
>          --MarkM
> 

_________________________
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