[cap-talk] "Same" key

[David Hopwood]

Norman Hardy wrote:
> On Feb 4, 2007, at 2:19 PM, Dean Tribble wrote:
> 
>>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.
> 
> This is an interesting case. I think I would provide two descriptions  
> for such a service.
> The first would be addressed to those who use the service and I would  
> describe the service as one object and strive to write the code to  
> conform to any resulting implications.
> To those who need to understand the code that defines the behavior, I  
> would refer to several 'real' objects, with a hopefully short  
> appendix on why it appear as one.
> 
> This is one of those many situations where we shift our manner of  
> speaking in a way to confuse new-comers.
> I don't see an alternative.

The alternative is to say that the service is a composite, and to describe
its overall functionality, its facets, and its internal objects.

Isn't this precisely the kind of case that the "composite" concepts and
terminology are designed to address, without need for any audience-specific
terminology shifts?

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