UP

Gnosis does not require object-style programming but it does support the designer of an object type in enforcing the rule that only his code will access the object’s representation. No programming discipline or compiler attributes are required on the part of other software builders.

Objects are known to their owner {as distinct from their creator} by keys held by the owner.

The same construct can, in different descriptions, be equally validly described as one or two {or more} objects. We might describe our communicating calculator above as two associated objects or as a single object. We chose according to which summons the best connotations. If we describe these systems as a single object, we can say that different programs have different capabilities concerning them in the form of different keys.

Consider the record collection. {A record collection serves about the function of a VSAM file.} A record collection is an example best described as one object even though different “owners” will have different rights to that collection. If we described a collection as two objects we would have to explain how a write operation on the writable collection would change the behavior of the other object. This seems confusing. In the case of the record collection we have another possibility: we can describe the read-only key as being to an object that somehow refers to a read-write capability to the first object. This discussion is continued at (p1,adt) after the idea of domain has been fully developed.