[cap-talk] "Same" key

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Thu Feb 15 16:26:23 CST 2007


Norman Hardy wrote:
> On Feb 6, 2007, at 8:47 PM, Mark S. Miller wrote:
> 
>>Regarding the KeyKOS literature, I'm confused about what they mean by
>>"object". The KeySAFE paper in particular is careful to distinguish  
>>"TCSEC object" from "KeyKOS object" and to always use the prefixed form  
>>for the latter. Can any of the KeyKOS crowd/community clarify what the KeyKOS
>>literature meant by "object"? Is the KeySAFE paper consistent with your usage
>>elsewhere?
> 
> The page from the Gnosis manual written circa 1980 is what I meant then:
> http://agorics.com/Library/KeyKos/Gnosis/2.html
> It still feels comfortable to me now.

It seems to make some statements about what it calls "objects", that are not
true of composites/abstractions. For example:

# Consider the concept of an object and the data that represents the state of
# the object. We say that a system supports objects if the following rules are
# obeyed, whether enforced by programming discipline, compiler design or operating
# system structure.
#
# The code that accesses the object representation is fixed and known to the
# system as a single unit and that code is the only code that accesses the object
# representation.

This ("known to the system as a single unit") is not true of a composite.

# Objects sharing the same code are said to be of the same type.

A composite does not have an overall type; its objects have types. (Any
classification of composites is relative to a specific analysis of the
system.)

# Any method of accessing the object is by some mechanism that we call
# here an "object name". The object name effectively designates both the
# object representation and the unit of code that has sole access to that
# data. {An obvious general idea is to have a pointer to the code stored
# in the data.}

This also seems to be talking about single/atomic objects.

> It might be less specific than what we need now as it was meant to  
> convey a style of software design, and not to support precise  
> categories.

Indeed.

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



More information about the cap-talk mailing list