Split Capabilities: Making Capabilities Scale

[Karp, Alan]

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.

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.

_________________________
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


> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Monday, July 24, 2000 2:46 PM
> To: Karp, Alan
> Cc: 'Jonathan S. Shapiro'; e-lang@eros-os.org
> Subject: RE: Split Capabilities: Making Capabilities Scale
> 
> 
> 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
>