Split Capabilities: Making Capabilities Scale

[Mark S. Miller]

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.  


>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".


         Cheers,
         --MarkM