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

[Toby Murray]

On Fri, 2007-02-16 at 23:51 +0000, David Hopwood wrote:
> Toby Murray wrote:
> > 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 think we agree based on the reading of your response to Pierre
Thierry's message, it's just that I didn't phrase the above as well as I
might have. What I meant was: if object means 'atomic object' in the PL
context, then since both facets and composites are implemented as atomic
objects, they are both certainly implemented as 'objects'.

>From my understanding of the object cap model, a facet is modelled
within the object-cap model as a proxying atomic object. Hence, a facet
is an 'object', in the PL sense. The object cap model only deals with
(atomic) objects. The 'composite' is also modelled within the object cap
model as an atomic object with references to its facets. So again, just
as with the PL case, we're only talking about objects. I don't see why
both can't be called objects then since this is their formulation within
the object-cap model after all.

The fact that some implementations of the abstract object cap model
might  choose to implement a composite as something different should not
confuse the terminology used to describe the abstract model (that by its
nature is applicable to multiple implementations -- hence its
usefulness).

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

With respect, implying that one does not understand "abstraction"
because we disagree about how terminology should be applied is not
helpful. I'm also certain that it's not being "misunderstood" as much as
being viewed from different points of view.

> 
> > 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,

Right, but I thought we were talking about access control outside of the
scope of the object-cap model here. In the same way that referring to
Hoare's  paper refers to objects in the PL sense outside of the
object-cap model.

>  so in the application
> of access control terminology to the obj-cap model, the use of "object" is
> consistent.

But as I said above, the object-cap  model also views both composites
and facets as "objects" does it not? So the use of object for both seems
to tally here as well as with the access control example (Lampson's
access matrix etc.) given earlier.

>  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.
>