$8.1 OBJECTS 225 The definition of references makes no mention of implementation properties.A reference,if not void,is a way to identify an object;an abstract name for the object.This is similar to a social security number that uniquely identifies a person,or an area code that identifies a phone area.Nothing implementation-specific or computer-specific here. The reference concept of course has a counterpart in computer implementations.In machine-level programming it is possible to manipulate addresses;many programming languages offer a notion of pointer.The notion of reference is more abstract.Although a reference may end up being represented as an address,it does not have to;and even when the representation of a reference includes an address,it may include other information. Another property sets references apart from addresses,although pointers in typed languages such as Pascal and Ada(not C)also enjoy it:as will be explained below,a reference in the approach described here is typed.This means that a given reference may only become attached to objects of a specific set of types,determined by a declaration in the software text.This idea again has counterparts in the non-computer world:a social security number is only meant for persons,and area codes are only meant for phone areas. (They may look like normal integers,but you would not add two area codes.) Object identity The notion of reference brings about the concept of object identity.Every object created during the execution of an object-oriented system has a unique identity,independent of the object's value as defined by its fields.In particular: I1.Two objects with different identities may have identical fields. I2.Conversely,the fields of a certain object may change during the execution of a system;but this does not affect the object's identity. These observations indicate that a phrase such as "a denotes the same object as b" may be ambiguous:are we talking about objects with different identities but the same contents(11)?Or about the states of an object before and after some change is applied to its fields (12)?We will use the second interpretation:a given object may take on new values for its constituent fields during an execution,while remaining "the same object". Whenever confusion is possible the discussion will be more explicit.For case II we may talk of equal (but distinct)objects;equality will be defined more precisely below. A point of terminology may have caught your attention.It is not a mistake to say (as in the definition of 12)that the fields of an object may change.The term "field"as defined above denotes one of the values that make up an object,not the corresponding field identifier,which is the name of one of the attributes of the object's generating class. For each attribute of the class,for example date in class BOOK3,the object has a field, for example /832 in the object of the last figure.During execution the attributes will never change,so each object's division into fields will remain the same;but the fields themselves may change.For example an instance of BOOK3 will always have four fields, corresponding to attributes title,date,page_count,author;these fields-the four values that make up a given object of type BOOK3-may change. “Object identity”, The study of how to make objects persistent will lead us to explore further properties page 1052. of object identity§8.1 OBJECTS 225 The definition of references makes no mention of implementation properties. A reference, if not void, is a way to identify an object; an abstract name for the object. This is similar to a social security number that uniquely identifies a person, or an area code that identifies a phone area. Nothing implementation-specific or computer-specific here. The reference concept of course has a counterpart in computer implementations. In machine-level programming it is possible to manipulate addresses; many programming languages offer a notion of pointer. The notion of reference is more abstract. Although a reference may end up being represented as an address, it does not have to; and even when the representation of a reference includes an address, it may include other information. Another property sets references apart from addresses, although pointers in typed languages such as Pascal and Ada (not C) also enjoy it: as will be explained below, a reference in the approach described here is typed. This means that a given reference may only become attached to objects of a specific set of types, determined by a declaration in the software text. This idea again has counterparts in the non-computer world: a social security number is only meant for persons, and area codes are only meant for phone areas. (They may look like normal integers, but you would not add two area codes.) Object identity The notion of reference brings about the concept of object identity. Every object created during the execution of an object-oriented system has a unique identity, independent of the object’s value as defined by its fields. In particular: I1 • Two objects with different identities may have identical fields. I2 • Conversely, the fields of a certain object may change during the execution of a system; but this does not affect the object’s identity. These observations indicate that a phrase such as “a denotes the same object as b” may be ambiguous: are we talking about objects with different identities but the same contents (I1)? Or about the states of an object before and after some change is applied to its fields (I2)? We will use the second interpretation: a given object may take on new values for its constituent fields during an execution, while remaining “the same object”. Whenever confusion is possible the discussion will be more explicit. For case I1 we may talk of equal (but distinct) objects; equality will be defined more precisely below. A point of terminology may have caught your attention. It is not a mistake to say (as in the definition of I2) that the fields of an object may change. The term “field” as defined above denotes one of the values that make up an object, not the corresponding field identifier, which is the name of one of the attributes of the object’s generating class. For each attribute of the class, for example date in class BOOK3, the object has a field, for example 1832 in the object of the last figure. During execution the attributes will never change, so each object’s division into fields will remain the same; but the fields themselves may change. For example an instance of BOOK3 will always have four fields, corresponding to attributes title, date, page_count, author; these fields — the four values that make up a given object of type BOOK3 — may change. The study of how to make objects persistent will lead us to explore further properties of object identity. “Object identity”, page 1052