In the last post, I spoke a little about essentials and accidentals, but I didn’t try to define these terms. In this post, I touch upon their traditional definitions in philosophy, and then turn to the application of these ideas to object-oriented programming.
At the heart of the philosophical concepts of essentials and accidentals is the classification or categorization of the property of an object as being needed (essential) or as being possible (accidental). The use of the words ‘must’ and ‘could’ work nicely in this regard. Consider the following two sentences:
A mammal must have warm blood.
A mammal could have fur.
The first captures an essential property of a mammal (namely that it regulates its internal temperature) while the second describes an accidental (it may have fur like a dog or have no fur like a dolphin).
All this sounds simple enough in principle, but there are always problems in the application. The most common problem is that two people considering the same object won’t necessarily list the same number or type of its properties or classify them in the same way essential or accidental. These differences reflect differences in perception, perspective, and the context and relative importance that each person places on the object. For example, a mechanic may view a car’s essential properties as including weight, acceleration, torque, and engine displacement. A city planner may view a car’s essential properties to include how often it is driven, its average speed, and its fuel mileage.
To illustrate this idea in more detail let’s start by examining something as simple as an ideal geometric point in a two-dimensional plane, a favorite prop in Euclidean geometry. An essential property most people would agree upon would be that an ideal point actually takes up no space, that is to say that it is truly zero-dimensional. Others may expand the list of essential properties to include the notion that the point must have a location within the plane. The list of accidental properties is much harder to nail down (precisely because they are not ‘musts’) but could include things like the color of the point as drawn or imagined, the distance of the point from an arbitrary origin, and the coordinate system and values within it for the position of the point. Thus this simple object from high school geometry is not as sweet and innocent as it seems. Scratch below the surface and it reveals a surprising degree of complexity and a tenacious resistance in being precisely defined. The situation grows more complex as we turn our attention to composite objects – objects that are made of parts that we could characterize as objects in their own right.
The idea of assigning essential and accidental properties to an object becomes even more interesting when the object is not in the real world but is in cyberspace. In this context, we are not simply the natural philosopher trying to characterize the objects we find or create in our world in the hope of inferring something true about all objects of that type. As programmers, we become the first cause in the microcosm of our program, and our choices in understanding how and why we choose a particular definition reveal things both profound and interesting about ourselves as thinking beings.
The creation or definition of an object, or more precisely an object class, is a way of mapping a mental conception of the mode of being of the object into computer instructions for handling data about those modes. Defining what these terms mean precisely is a difficult endeavor but let me start by at least posing some questions to consider in order to help in fleshing these ideas out.
- What do the philosophical terms ‘essential’ and ‘accidental’ mean when we are the creators of the form of an object (i.e., the class)?
- Do the object properties represent an essential or an accidental property of an object?
- Is it true that the value of member data is always an accidental?
Again concrete illustrations will be much more useful. Consider an OOP representation of the ideal point, which is frequently presented in discussions about graphics primitives. A typical construction might look like (in a language-agnostic form)
Note that I am only dealing with the object’s properties and not how they are assigned or observed, so all the machinery that allows the object to interact with the outside environment (‘getters’ and ‘setters’) will be suppressed.
Now that we have defined our (computational) object let’s see if we can classify which parts of our object definition are essential and which are accidental. A curious point is now apparent: there is no obvious place where we specify that the agreed-upon essential property of an ideal geometric point is that it is zero-dimensional. Clearly all objects that are instantiations of the class ‘Point in a plane’ possess this essential property but they don’t know it and they can’t share it with the rest of the world.
It may seem that the only entity that knows this truth is the one who defined the object class in the first place. But a small amount reflection on how the programmer programs delivers a more likely explanation: that the creator doesn’t really need to identify or even be aware of the essential properties of the object. The creator simply employs the very capacity he uses to learn and interact with the world when he defines the class. He doesn’t know how he does it any more than a bird knows how it flies; he simply does. The programmer then depends on this capacity to know how many and which kinds of objects get instantiated to perform whatever computational task is desired.
What, then, to make of the object properties like ‘x_component’, ‘y_component’, and ‘color’? Are these essentials or accidentals? In some sense they are both. From the definition of the object class, these data are essential because they are required for all objects of type ‘Point in a plane’. But from the point-of-view of the programmer’s mental conception of what the object represents they are usually accidentals since their actual values are clearly not important. Changing the color of a point or moving it around in the plane doesn’t stop the object from being a point. So it is essential that the object has a memory location allocated to hold a value but it is completely accidental what value is inserted.