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

[Toby Murray]

On Fri, 2007-02-16 at 17:29 +0000, David Hopwood wrote:
> 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.

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


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. It depends on the level of
abstraction, as always.

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