[cap-talk] "Composite", was "Same" key

[Mark S. Miller]

David Hopwood wrote:
> What composite does the set of zero objects implement? If there were some
> technical advantage in including the null set, that would be fine, but I
> don't see any.

I am thinking in terms of descriptions like

     Say Alice is one of Bob's clients. Let's describe the set of all of Bob's
     other clients as the composite Rest. If Alice uses Bob correctly and Bob
     is defensively consistent, then, no matter what action is taken by Rest,
     Bob will never give bad service to Alice.

In this description, the composite Rest "implements" a potentially misbehaving 
client of Bob. Since, in an object-capability system, Bob can't sense which 
client makes a request, for some purposes, we might as well aggregate all 
potentially misbehaving clients of Bob into a single descriptive composite.


> I agree that a SCOLL aggregate entity should allow the empty set of objects
> (which holds no permissions), but it would be perfectly reasonable to allow
> that while saying that such a set does not implement a composite.

Why?



>> I do not dispute that this makes the "composite" term yet stranger from
>> a conventional English usage perspective. But I don't think any of the
>> alternatives proposed so far are better.
> 
> What do you see as being the disadvantages of "abstraction"?
> 
> (So far, the only disadvantage that has been put forward for "abstraction" is
> that it may be too general. That seems less serious to me than conflicts with
> either common English usage, or OO programming language terminology.)

Yes, I am uncomfortable with "abstraction" for this reason. While a composite 
itself often represents something we'd naturally describe as an abstraction, 
sometimes it doesn't. For example, the set of objects hosted by VatB form a 
composite. From my section 7.5:

# Even if VatB is run on a corrupted operating system or tampered hardware, or
# if it runs its objects in an unsafe language like C++, Alice could still
# view it as a set of colluding objects running on a properly functioning vat.
# If Betty, another C++ object in VatB, steals Bob's reference to Carol, from
# Alice's perspective this is equivalent to Bob colluding with Betty.
#
# A misbehaving vat can misuse any of the remote references given to any of
# the objects it hosts, but no more. This is also true of a colluding set of
# objects running on a correct vat. If Alice's programmer wishes to defend
# against VatB's possible misbehavior, she can model VatB as a monolithic
# composite, and all its externally accessible objects (such as Bob and Betty)
# as facets of this composite. Alice's programmer can, without loss of
# generality, reason as if she is suspicious only of objects.

However, the set of objects hosted by VatB don't necessarily have anything 
else in common other than being co-resident, so I'd find it strange to refer 
to this set as an "abstraction". I'd say that some composites are 
abstractions, such as the set of objects instantiating a caretaker pattern. 
But some aren't, such as the set of objects hosted by VatB, or the set of 
non-Alice objects which are clients of Bob.


-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM