[cap-talk] "Same" key

[Norman Hardy]

On Feb 9, 2007, at 4:39 PM, David Hopwood wrote:

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

I agree with earlier points made by you and others about the  
importance of a uniform terminology but still I must say why I don't  
like to talk as you do above.
If I am writing to tell programers how to use the function I have  
created, I want them to think of a whole--a unit--a single  
thing--'one unit of entangled state' regardless of how I implement it  
and regardless of whether there are differing authorities which they  
and their deputies may hold to that thing.
The ordinary English connotation of 'composite' serves poorly here.

If I am documenting my implementation for someone to modify, I shall  
probably need to describe the 'real' component parts and then  
'composite' serves well.

The output from one phase of a program is the input to the next phase.
Calling that data both input and output can certainly confuse until  
the reader is well oriented.
After orientation those terms profitably invoke familiar images.

Another form of documentation is where we describe general object  
discipline. That discipline should perhaps include or encourage a  
style of documentation including terminology,

I think that there was an agreement that facets should be relegated  
to a pattern rather than a fundamental aspect of object terminology.
I reluctantly concur for two reasons:
    Reducing the fundamental constructs is good.
    Some platforms do not provide the the construct fundamentally.
I am reluctant merely because it was so easy and efficient to provide  
this construct fundamentally in Keykos.

I think that my all-time favorite manual was the IBM 370 hardware  
manual.
They did not do what I advocate here and I shall have to write a  
small essay to explain the discrepancy.
I think(!) that that manual entirely eschewed abstraction even as it  
described a hardware platform that allowed the user (OS writer) to  
generate abstractions.

> -- 
> David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk