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

[David Hopwood]

Toby Murray wrote:
> On Fri, 2007-02-16 at 17:29 +0000, David Hopwood wrote:
> 
>>"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.
> 
> But isn't it the case that in all current object-cap languages, that a
> composite is implemented as an atomic object anyway, since the languages
> don't make a distinction between atomic/composite anyway.

It is not that the languages don't make a distinction; it is that composites
belong to some description of the system above the language layer. They aren't
present at the language layer at all.

(Exception: some "component-based" coordination languages do have multi-object
structuring concepts supported by the language. A quick Google search found
<http://www.cs.iastate.edu/~leavens/SAVCBS/2005/posters/Serrano-Sanchez-Alonso.pdf>,
for example.)

In this sense a composite is like an informal specification of a [static] type
used to describe the behaviour of a program written in an entirely dynamically
typed language. (Does this analogy help anyone?)

> And that facets are implemented as proxying atomic objects. From my
> understanding of E and the definition  of "atomic object", file, fileReader
> and fileWriter below are all (as far as E is concerned) atomic objects that
> happen to have references to other atomic objects. So in a literal
> sense, if "object" in the context of historical use in object-based
> programming languages means "atomic object" (in the context of this
> message and the current definition of "atomic object") then, a
> "composite" in E is certainly an "object" in the context of historical
> use in object-based languages.

No. Each facet of a composite is an object.

[I'm genuinely bewildered by why this idea is being misunderstood by so many
participants in this thread. Isn't an understanding of abstraction essential
for programming? MarkM's account precisely matches my understanding of the
most common form of abstraction used in object-based systems.]

> def file {
>     def fileReader {
>         to read() { }
>     }
>     def fileWriter {
>         to write() {}
>     }
> }
> 
>>"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.
> 
> I'm not sure I agree. In Lampson's access control matrix, for example, a
> "composite" file of two "read" and "write" facets would be modelled as a
> single "object" with read and write rights.

But in the obj-cap model, the only right is invocation, so in the application
of access control terminology to the obj-cap model, the use of "object" is
consistent. Also see the discussion of Hydra below: even in cases where there
is more than one access right, an access-control-object is a more restricted
concept than a composite. So using Charles Landau's terminology would still
result in a clash of meaning between a Landau "object" and an access-control
"object".

[...]
>>"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.

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