[cap-talk] "Same" key

[Dean Tribble]

KeyKOS et al, Joule, E, concurrent constraint languages, etc. all have
characteristics that makes the notion of "object" somewhat confusing
and in some cases irrelevant.  For example, with explicit
communication channels (e.g., Joule, E, FCP), a reference is the
send-side of a channel (an acceptor port in Joule, a promise in E) and
the "object" is (approximately) whatever holds the receive side (a
distributor in Joule, a resolver in E) and responds to messages
appearing there.

That analogy breaks down fairly quickly for programs that take
advantage of the communications architecture to implement message
plumbing (which I believe is a crucial new form of abstraction).  We
wrote many examples in which multiple concurrent processes extract
messages from the receive side (which one is the "object"?), the thing
receiving messages changed over time, or the thing receiving messages
handled some and deferred other elsewhere.  "Objectness" from the
client's perspective (the message sender) was thus generally stretched
across several implementation objects.  Similarly, with direct support
for facets (e.g., Joule facets, KeyKOS capability bits, etc.), an
implementation object might appear to be several different "objects"
from it clients' perspectives.

Thus, the notion of objects is confusing, but the notion of references
remains coherent.  It's the references that are capabilities,
comparable, etc.  I think this perspective is coherent, and I expect
that we can find consistent terminology for discussing it, mostly by
not trying to have a single term "object" that simultaneously means
the implementation artifacts for an abstraction, the client's
perspective on the abstraction, and the reference distinctions in the
abstraction.

I need to go review MarkM's current definition.  The common PL concept
(i.e., from Smalltalk) is just a special case (albeit important one)
of the required concept in languages with message plumbing
(communication channels that programs can manipulate explicitly)
and/or facet support.

PS Ken Kahn first articulated this stretching of the object notion in
a way that I "got it", though as with much of concurrent logic
languages, Udi Shapiro probably had already internalized it :-).  I
think it was in "Language Design and Open Systems" by Ken Kahn and
Mark Miller.

> > More practically -- and this exposes a place where I continue to be

> I do think the dominant use of "object" in computer science is what
> "object-oriented programmers" mean by "object" -- a combination of state and
> behavior that reacts in a certain way to messages/invocations. Certainly, we
> have been clear that the "object" in our term "object-capability model" is a
> reference to the "object" of "object-oriented programming" (or "object-based
> programming" if one buys Wegner's taxonomy).
>
> So, in spite of your attempts to redefine terms ;), I will continue to speak
> in terms more familiar from the PL perspective, even if that's more confusing
> from the OS or historical access control perspectives.

I think that the "traditional" concept of object is not sufficiently
expressive to be clarifying in a discussion of equality in these more
complicated systems, so we should simply avoid using the term :)