Requisitos y procedimientos de acceso 1 Difusión

Some data behave like mathematical objects and other data behave like representations of physical objects (MacLennan 1983).

Consider the sets { 1, 2, 3 } and { 2, 3, 1 }. Although these sets have different representations (the ordering of the members is different), they have the same value because in set theory the only important property of a set is the members that it contains: “two sets are equal if and only if they contain the same members”.

Consider two objects representing people: [name="Peter", age=55] [name="Peter", age=55]

Although these objects have the same value, they might refer to different people who have the same name and age. The consequences of assuming that these two objects denote the same person could be serious: in fact, innocent people have been arrested and jailed because they had the misfortune to have the same name and social security number as a criminal.

In the following comparison of values and objects, statements about values on the left side of the page are balanced by statements about objects on the right side of the page.

Values

Integers have values. For example, the integer 6 is a value.

Objects possess values as attributes. For example, a counter might have 6 as its current value.

Values are abstract. The value 7 is the common property shared by all sets with cardinality 7.

Objects are concrete. An object is a particular collection of sub- objects and values. A counter has one attribute: the value of the count.

Values are immutable (i.e., do not change).

Objects are usually, but not necessarily, mutable (i.e., may change). It does not make sense to change a value. If we change the value 3,

it is no longer 3.

It is meaningful, and often useful, to change the value of an object. For example, we can increment a counter.

Values need representations. We need representations in order to compute with values. The representations 7, VII, sept, sju, and a particular combination of bits in the memory of a computer are dif- ferent representations of the same abstract value.

Objects need representations. An object has subobjects and values as attributes.

It does not make sense to talk about the identity of a value. Suppose we evaluate 2 + 3, obtaining 5, and then 7 − 2, again obtaining 5. Is it the same 5 that we obtain from the second calculation?

Identity is an important attribute of objects. Even objects with the same attributes may have their own, unique identities: consider identical twins.

We can copy a representation of a value, but copying a value is meaningless.

Copying an object certainly makes sense. Sometimes, it may even be useful, as when we copy objects from memory to disk, for exam- ple. However, multiple copies of an object with a supposedly unique identity can cause problems, known as “integrity violations” in the database community.

We consider different representations of the same value to be equal.

An object is equal to itself. Whether two distinct objects with equal attributes are equal depends on the application. A person who is arrested because his name and social insurance number is the same as those of a wanted criminal may not feel “equal to” the criminal. Aliasing is not a problem for values. It is immaterial to the program-

mer, and should not even be detectable, whether two instances of a value are stored in the same place or in different places.

All references to a particular object should refer to the same object. This is sometimes called “aliasing”, and is viewed as harmful, but it is in fact desirable for objects with identity.

Functional and logical PLs usually provide values.

Programs that use values only have the property of referential trans- parency.

Programs that provide objects do not provide referential trans- parency, but may have other desirable properties such as encapsula- tion.

Small values can be held in machine words. Large values are best represented by references (pointers to the data structure representing the value.

Very small objects may be held in machine words. Most objects should be represented by references (pointers to the data structure holding the object.

The assignment operator for values should be a reference assignment. There is no need to copy values, because they do not change.

The assignment operator for objects should be a reference assign- ment. Objects should not normally be copied, because copying en- dangers their integrity.

The distinction between values and objects is not as clear as these comparisons suggest. When we look at programming problems in more deatil, doubts begin to arise.

Exercise 41. Should sets be values? What about sets with mutable components? Does the model handle objects with many to one abstraction functions? What should a PL do about values and objects? 2

Conclusions:

. The CM must provide values, may provide objects.

. What is “small” and what is “large”? This is an implementation issue: the compiler must decide.

. What is “primitive” and what is “user defined”? The PL should minimize the distinction as much as possible.

. Strings should behave like values. Since they have unbounded size, many PLs treat them as objects.

. Copying and comparing are semantic issues. Compilers can provide default operations and “building bricks”, but they cannot provide fully appropriate implementations.