Split Capabilities: Making Capabilities Scale

[Norman Hardy]

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.

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.

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.
Norman Hardy  <http://www.mediacity.com/~norm>