3.2 Names

Recall [ISO95a, Clause 12] that a name is defined only within a particular naming context. Some names are unambiguous in their contexts and are called identifiers. Thus, an entity (of which an object is a model) can have several names, and several identifiers, within a particular naming context. In order to designate an entity, its identifier should be made visible. As the names (and identifiers) of an entity may be created, changed, and deleted, and the naming contexts may also be created and deleted, we need some property of an entity which will be independent of names and naming contexts, but will distinguish an object from any other object, as required by [ISO95a, Clause 8.1]. Surrogate is such a distinguishing property of an object, and it is not necessarily made visible. Hall calls this property ``object identity" and models it in Z by a schema component called ``self". It is independent of any naming context: indeed, a property distinguishing between objects should not disappear when a particular naming context is deleted! Since the representation of a name as, for example, a character string is ambiguous without the naming context - a certain string of digits could easily be a name of an insurance policy in one context and a name of a savings account in another - the full representation as an ordered pair (name,context) is needed in general. In a very simple specification, such as one with only one naming context, this representation could also be simplified.

The pool for surrogates is obviously independent of any naming contexts. Thus, when an object (in fact, an object instance - we will clearly distinguish between object types, classes, and instances, and ``object" will usually mean ``object instance") is created, a new (``fresh") surrogate value is taken from the surrogate pool, and a new pair is added to the surrogate - object relation. (This relation is a partial bijection: any object has exactly one surrogate corresponding to that object.)

A fragment of toolkit concerned with name operations should include creation and deletion of a naming context, as well as creation, deletion, and changing of a name within a given naming context. These operations are quite straightforward. However, as it should be always possible to designate an object, it should always have at least one identifier (and therefore at least one naming context) - these are conjuncts of the invariant of an object. Whether a particular context may have only names, and not identifiers, is an interesting issue - it would seem the answer should be ``yes" as long as there exists at least one identifier in any naming context. Imagine a context in which otherwise different things (``objects") become indistinguishable (``any software engineer can be replaced with any other software engineer with approximately the same experience"). Notice that these issues become explicit as a result of the need to create a formal specification (even without writing the specification itself).