[cap-talk] "Same" key

[David Hopwood]

Dean Tribble wrote:
> 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"?),

They are all objects, as is each facet of the channel.

(Joule is more expressive here than almost all other object-capability
systems, so it is not surprising that this facility needs to be modelled
by reifying the concept that is not present in other systems as an
additional object or objects.)

> the thing receiving messages changed over time,

If the change can be modelled simply as a state change, then it's the
same object. If we are redirecting the channel to a different destination
(in such a way that both the previous and new destinations remain
separately invokable), then we have directed it to a new object.

> or the thing receiving messages handled some and deferred other elsewhere.

'Elsewhere' is a different object.

> "Objectness" from the
> client's perspective (the message sender) was thus generally stretched
> across several implementation objects.

The obj-cap model explains that by saying that the client is seeing a
facet of some composite.

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

There is no ambiguity here; they are different objects, even if they
are implemented by the same domain/server.

> Thus, the notion of objects is confusing, but the notion of references
> remains coherent.

I disagree. The notion of objects used in the obj-cap model is quite
straightforward, and can model all of the examples above easily.

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