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

[David Hopwood]

Toby Murray wrote:
> On Fri, 2007-02-16 at 16:23 +0000, David Hopwood wrote:
>>Charles Landau wrote:
>>
>>>That is exactly why there should be a term for "a set of one or more 
>>>related atomic objects".
>>
>>Yes: "abstraction". But Jonathan claims that is too general. So, unless
>>someone wants to propose another alternative, we have only the following
>>choices:
>>
>> - use "composite", and accept that the special case of a single object is
>>   not motivated by the everyday meaning and will have to be learnt.
>>
>> - use "abstraction", and accept that it is a more general word than we'd like.
>>
>> - use "object", and accept that this is inconsistent with the majority of
>>   current and historical usage in object-based systems, going back to 1965.
>>
>>To me, consistency of terms within a given technical field trumps consistency
>>with everyday meanings, every time.
> 
> I've been following this discussion but can't remember seeing anything
> about object meaning >=1 atomic objects being inconsistent with
> historical and current usage in object-based systems. Sorry if I'm
> asking for evidence that has already been presented, but could you give
> some examples?

"Object" in object-based programming languages always means an atomic object.
This was the terminology used in Tony Hoare's "Record Handling" article,
adopted by Simula 67 <http://heim.ifi.uio.no/~olejohan/birth-of-oo.pdf>
and Smalltalk, and used consistently with that meaning in every object-based
programming language since, AFAIK.

"Object" in access control terminology means an entity on which it is possible
to perform primitive operation(s) that are subject to access control. This is
not a composite: a composite with multiple facets would have to be modelled as
multiple objects in the access control sense.

"Object" is also used in the terminology of the Hydra OS. Even though Hydra
has more access rights than just an "invocation" right (and so a Hydra object
would need to be modelled as more than one atomic object in the obj-cap model),
a Hydra object cannot be a general composite -- it is implemented by a single
server and has a single concrete type.

So far, the only systems mentioned in this thread for which "object" meant
"composite" are the KeyKOS family of OSes. Even then the KeyKOS documentation
is not entirely consistent: sometimes it uses "object" in ways that can only
be referring to atomic objects.

[...]
>>Terms should be, as far as possible, *motivated* by common usage in order
>>to be easier to learn; that doesn't mean that there won't be special cases
>>that are less well-motivated. In this particular case, as in many others,
>>we cannot choose a set of terms that are entirely free of flaws; we have
>>to pick the one with the fewest or least important flaws.
> 
> Well put. The trouble might be on deciding which flaws are more (or
> less) important than others. The goal (and hence, the audience for these
> terms) should be clear, or else we're doomed to continue arguing in
> circles.

If we are going for the biggest audience who are likely to be receptive
to object-capability ideas, then that is programmers who know one or more
object-based programming languages.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>