Split Capabilities: Making Capabilities Scale

[Mark S. Miller]

At 10:37 AM 7/24/00 , Karp, Alan wrote:
> > From: Mark S. Miller [mailto:markm@caplet.com]
> > 
> >      define incDecPair new(x) :any {
> >          [define incr do { x += 1 },
> >           define decr do { x -= 1 },
> >           define getX() :any { x }]
> >      }
>
>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.

This *is* a pure object model, and a purely and securely encapsulated one.  
These three facets are all "forseen" facets, in Norm's wonderful 
terminology.  All three facets were forseen and arranged for by the designer 
of the state that they share.  Encapsulation is the inability of anyone 
outside this arrangement from reading of effecting this state in ways not 
provided for by this arrangement.

To show that there's nothing magic going on, the above code is semantically 
equivalent to the following arrangement involving explicitly and 
conventionally separate objects:

     define XHolderMaker new(x) :any {
         define xHolder {
             to getX :any { x }
             to setX(newX) :any { x }
         }
     }

     define IncrMaker(xHolder) :any {
         define incr do { xHolder setX(xHolder getX + 1) }
     }

     define DecrMaker(xHolder) :any {
         define decr do { xHolder setX(xHolder getX - 1) }
     }

     define GetXMaker(xHolder) :any {
         define getX() :any { xHolder getX }
     }

     define incDecPair new(x) :any {
         define xHolder := XHolderMaker new(x)
         define incr := IncrMaker(xHolder)
         define decr := DecrMaker(xHolder)
         define getX := GetXMaker(xHolder)
         [incr, decr, getX]
     }

If you have no problems with the longer front-ending style, you have no 
ground for problems with the shorter style.  The shorter style is, in a way, 
purer, since all object systems are most cleanly understood in terms of the 
lambda calculus augmented with local side effects, and the shorter style 
makes more direct use of the power inherent in that formalism.  However, 
when facets are unforseen, only the longer style can be used.

For you KeyKOS/EROS types, the shorter style corresponds to different start 
keys (having different data-bytes) to the same single domain, whereas in the 
longer style each domain has only a single start key, and four domains are 
needed.


         Cheers,
         --MarkM