Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Norman Hardy [mailto:norm@netcom.com]
> Sent: Tuesday, July 25, 2000 9:05 PM
> To: Karp, Alan; 'Dan Bornstein'
> Cc: e-lang@eros-os.org
> Subject: RE: Split Capabilities: Making Capabilities Scale
> 
> 
> At 16:22 -0700 00/07/25, Karp, Alan wrote:
> >As I said in my first reply to Mark, if I know the full 
> interface, I don't
> >have a problem.  What you describe is exactly this 
> situation.  The "object"
> >is the state plus the behavior represented by the union of 
> all the facets,
> >not just the facet I hold.  Mark stated quite explicitly 
> that "no automatic
> >awareness is provided".  It is this lack of awareness that 
> prevents my
> >thinking of the facet as an object.  If von Braun is unaware 
> of a facet
> >allowing increment, and he treats the facet as an object, he 
> must assume
> >that any increase in the counter is due to a fault in the 
> counter mechanism.
> >
> 
> An interesting point. Someone must presumably know the total 
> behavior of
> the object inorder to employ it. Not all of the holders of 
> facets need do
> so, however.

If they don't, then I argue that they can't reason about the object.
 
> The increment facet of the updown counter may be delivered to the car
> counting agent at the garage entrance while the decrement 
> counter facet is
> delivered to the counter at the exit. The read counter facet 
> is delivered
> to the agent that drives the capacity advisory sign. Whoever 
> created the
> counter instance probably had to be designed with the total 
> function in
> mind. He is out of the loop soon after creation of the counter.
> 
> The minor facets are held by programs that are very specialized. It is
> useful to know who to suspect if the counter gets too large.

That's my point.  I need to know the full interface to know who to suspect.

Hmmm.  That's gotten me thinking (always a dangerous thing).  If I know the
full interface, I can reason about the object even if I only have a facet.
However, I may not need that much information.  All I really need is
knowledge of the possible state transitions.  Thus, Werner von Braun doesn't
need to know that there is an increment method, only that the counter can
increase.  I can then reason about an object with much less information.   I
expect that it is possible to construct a formal definition of object along
these lines.

> 
> I wont fight over the word "object" but I think you have an 
> interesting
> distinction. It is clear that someone must know the whose 
> semantics of the
> counter, probably the designer of the program that creates 
> the instance;
> but the facets are then diseminated on a need-to-invoke bases.
> 
> I wrote a little note at
> <http://www.mediacity.com/~norm/CapTheory/ObExp.html> this 
> afternoon on a
> closely related subject.

I like the definition of object at that URL, but I don't see the problems
with Y and Z.  If I send a message to X, and X uses some complex processing
to satisfy my request, including invoking Z which may affect the state of X,
who cares?  Similarly, if Y can invoke a method that changes the state of X,
who cares?

I think the problem is that you're assuming that I know the state of X
before I send the message.  Unless I'm the only one who can change that
state, or if I can lock out changes, there's no way for me to have that
knowledge.  If you assume that the initial state of X is unknown to me
before I send the message, then I think your three rules hold.

> Norman Hardy  <http://www.mediacity.com/~norm>
> 

_________________________
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