Inherence and Nonsubstantial Particulars: An Object-Oriented View Samuel H. Kenyon

Size: px

Start display at page:

Download "Inherence and Nonsubstantial Particulars: An Object-Oriented View Samuel H. Kenyon"

Job Golden
5 years ago
Views:

1 Inherence and Nonsubstantial Particulars: An Object-Oriented View Samuel H. Kenyon 09/29/04

2 Kenyon 2 Introduction In order to tackle the meanings, assumptions, and inconsistencies in Aristotle s Categories[1], and now Metaphysics, I translated as much as I could conceptually into a framework I am more familiar with Object-Oriented Programming (OOP). OOP is a design paradigm for computer programming, with associated languages, diagram standards, etc [2]. Regardless of your OOP experience, the object-oriented analogies will make sense if you keep in mind that objects are (for the most part) just containers of attributes (variables) and methods (functions). That and various class relations are enough for a programmer to model any real world object, concrete or abstract. I do not mean to propose that metaphysics is OOP, or that a divine entity/process designed the physics (the world) with object-oriented metaphysics. I will explicate that in another paper. Nor are the objects in this paper necessarily the same as in any other metaphysical context. So the first question is, can these objects (class instantiations) describe the subjects of inhesion, or that which is inhered, or both? My view is that class instantiations can describe both, but then there is the question: Can objects be nonsubstantial? In this paper I will develop my object-oriented description and then compare my analogies with other interpretations of the Categories inherence issue. Inherence According to the dictionary [3], inherence is The fact or condition of inhering; the state or quality of being inherent; permanent existence (as of an attribute) in a subject; indwelling. Consider this as a link to the object-oriented view: This relation of inherence and permanent coexistence in one nature is expressed by the word attribute [4]. How one thinks of attribute is important. Defining or describing properties of an object as being inside said object may follow from how one models or abstractly conceives the object or its class. It is worth mentioning that in OOP, diagrams of classes (and/or objects instantiated from these classes) usually show the attributes (properties) and methods inside the box representing the class. So when one actually tries to draw the concept of an object, if it is a block diagram it makes sense to show the attributes inside the object. Even if the attributes are drawn in their own boxes and connected to the class, or if the diagram is a tree or outline diagram, one can still map between the inside diagrams and the other forms. In order to further discuss inherence, we must describe predication. In the Categories Part 2 (1a16), Aristotle gave four kinds of things based on a combination of two kinds: predicated of or said of a subject, depending on the translation present in or in a subject The second one, in, is referring to inherence. To avoid confusion with the word predication we can use Moravcsik s idea [5] of two senses of predication predicated on top of (predicated + inherence). Moravcsik gives this example: For example, man is predicated of Socrates, but man or manhood is predicated of Socrates; white is to be predicated but white or whiteness inheres in men. Let us assume that the first predicated should have been written as predicated to maintain lexical consistency. This should help clear up the linguistic versus ontological issues for inherence. Here is a key OOP insight: The said of predication (predication ) is analogous to class inheritance 1. When a child class inherits its parent, what it is inheriting are attributes and methods 2. We are not dealing with objects themselves now, but with classes. Said of and said of the predicate translate to is the parent class of. It follows that in reverse, predicated translates to is-a. Species and genera are child- 1 It is most likely public inheritance, but for simplicity in this paper we will ignore public/private qualifiers. 2 For our purposes we can clump methods along with attributes and just call them attributes or properties.

3 Kenyon 3 parent relationships, and can be mapped onto this system of class hierarchies. Animal is-a LivingOrganism; Human is-a Animal. My interpretation of Dancy's view [6] is that all things are said of, and the in relationship is just a way of referring to the inherited properties of a subject. Dancy said, What is in the subject is the abstraction or property correlated with that predicate. This seems to fit with OOP except that we have to allow properties that are not inherited, otherwise there would be no specialization. Whatever an object contains (i.e., inheres) is displaying a has-a relationship, regardless of any is-a connections. Differentiae If a subject s attributes are nonsubstantial particulars, it follows that differentiae are inheritable nonsubstantial particulars, because the OOP view does not distinguish between properties and differentiae they are both attributes. We will return to nonsubstantial particulars shortly. In OOP when you inherent you are not only making an is-a relationship, but the derived object is actually constructed with an object of its parent class contained inside it, very much like the specialized properties already contained by this child object. Say we have a class called Human. We also define a subclass Philosopher that is-a Human. Philosopher adds some attributes to Human, such as BasketsWoven (a quantity particular). Given Philosopher P, we can access P.BasketsWoven and P.HairColor, but HairColor is really coming from the Human object inside of P. Philosopher is a Human the greater class is predicated of the lesser, so that all the differentiae of the predicate will be differentiae also of the subject (Categories 1b22). Philosopher is said to be the lesser here because it is the subject and Human is the predicate. Although all Humans including Philosophers can be differentiated by HairColor, not all Humans can be differentiated by BasketsWoven whereas all Philosophers can be. The Has-A Relationship Has-a means containment. When you say Socrates is pale or Socrates has pale, you really mean in the metaphysical framework: Socrates.Complexion == light where light could simply be a point along some gradient of values that can be assigned to Complexion; indeed Complexion must at all times have some value. Or: Socrates.Pale == true which implies that: Socrates.Toasted == false So what, then, is.pale here? The OOP view has not yet explained any better what kind of being paleness is, even if we force the format to be a single Complexion with many possible states instead of many attributes of the Pale kind that are all boolean. What kind of beings are those that we refer to with inherent labels? In object-oriented programming the obvious answer is that the inherent properties of an object are themselves objects 3. In fact, an object-oriented programmer has no qualms about making a class that contains an object of that same class 4. So we still have this problem: Are the inherent objects substances? Can they exist on their own? Right now they are not substances, they are nonsubstantial particulars. Let us compare what others have to say on inherence and nonsubstantial particulars. Nonsubstantial Particulars 3 Yes, most languages include intrinsic types (e.g., integers), but as variables they can be thought of as objects, and intrinsic types can be thought of and often used just like classes. 4 Of course, in computer programming, design time, compile time, and run time are all well defined. Only at run time (execution) is a class instantiated into an object.

4 Kenyon 4 The OOP view as I have developed it concurs mostly with Ackrill s view as defined by [7]; this will be shown shortly. So far the OOP view has not made a distinction between properties and parts. Are they both attributes of the subject? This difference, whether grammatical or ontological must be worked out, otherwise we may be conflicting with Aristotle out of the bounds of reinterpretation. Ackrill and Owen both require x to not be a part of y, but it is Frede s account that is most potentially hazardous to the OOP view. As described by [8], Frede interprets part as part of the definition. It seems that any attribute of an object is part of its definition and thus fails Frede s formula. However, that can be fixed if we say definition is the class, and specify x as an object. We are mostly dealing with classes though, not the instantiations. Also, Frede s account may still be incompatible with OOP because of his one-place predicate interpretation, as [8] says, he is defining what it is to be an accident, the sort of thing that is in a subject, rather than what it is for x to be in y. Subject properties are attributes instances within an instance. Are these attribute objects tropes? Since there are so many different versions of trope theory [9] I will not digress on them, except to say that inhered objects are similar to tropes. The inhered is always, however, a particular. But wait, you say: These are classes, thus universals (with limitations), thus they are shareable and not particular. The first rebuttal to that is: At the point of instantiation, however, the classes do become particulars. Multiple particulars can be of the same type. What you say? OOP to the rescue: the attributes in a subject are named as applicable for that specific subject. Even if attribute a of class C is in subject s, attribute x of type C in subject y can also exist. One instance is named a, and the other is named x. (Notice I freely interchange class and type.) This fixes the problem with Ackrill s account as outlined by [8]. My examples of x above seems to meet Ackrill s requirements without limiting the universal C to any one subject: 1. x:c belongs to y 2. x:c is not part of y 3. x:c does not exist separately from y (even though a:c does) As such, the object-oriented view has some problems. Here is one way to fix it so that we do not have attributes floating around outside of their containers, and so that there is still a difference between said of and in things: We could limit an inhered object to an instantiation of an inner class, which is defined inside the class that is instantiated into the containing object (the subject of inherence). No other class can have objects of that inner class, nor can an object of that inner class exist on its own therefore it also cannot be said of anything. Said of things would be defined with classes not inner, except in some theoretical class of all classes. This fix is flawed without serious mutation because it breaks our aforementioned non-limitation of universals between subjects. A more complicated solution would involve making an ontological equivalent of a programming namespace system, which we will not discuss. We can survive by merely realizing that the attributes can never float anyway, that is what the nonsubstantial categories categorize: quantity, quality, relation, place, etc. What fills in those columns are just the classes which do not alone indicate who is using them as attributes. You are not referring to attributes of class C unless you speak of the class D that inheres attributes of class C. As for differentiating said of and in classes, we want the flexibility to have things that are both and neither, as Aristotle had four combinations in Part 2 of the Categories. Figuring out how a nonsubstantial particular can or cannot be predicated or inhered should not seriously wound the rest of the OOP-inspired view as it applies to inherence. Object-Oriented Weirdness One weirdness of the object-oriented view is that when we are discussing the class hierarchy as it fits into

5 Kenyon 5 the Categories, all the subjects, including those that are in others, are being discussed in class form. They have not been instantiated yet until they get into our realm. Until the level of Socrates existing, his attributes are in classes above him. A lot is happening in those classes above him to get to the class(es) most specific to Human, and even more specific to the Socrates class (i.e., form) if there is one. Problems of priority and dependence are not answered so far with this view, except that a class must be defined before it can be instantiated. But in a metaphysical ontology, is there a temporal difference between class creation and object creation? If it must be a different type of priority or dependence, then the classobject mechanism (or just its temporal aspect) may need to be transformed into that ontological space somehow. As for turning classes into objects, I do not think that the question What is class instantiation? is any more mysterious now than how a form is related to an individual; indeed, it is now obvious that one can think of the how as a process or transformation, as a recipe even. References [1] Aristotle, Categories, tr. E.M. Edghill, 350 BCE. [2] Object-oriented programming, Wikipedia, [Online]. Available: [3] Oxford English Dictionary, second ed., [4] J. Martineau, Types of Ethical Theory, I. I. II. iii. 136, (As quoted by [oed].) [5] J.M.E. Moravcsik, Aristotle on predication, The Philosophical Review, Vol. 76, No. 1, Jan. 1967, pp [6] R. Dancy, On some of Aristotle s first thoughts about substances, The Philosophical Review, Vol. 84, No. 3, July 1975, pp [7] M. S. Cohen, In a subject in the Categories: Three Interpretations, [Online]. Available: [8] M. S. Cohen, Nonsubstantial Particulars, in The Stanford Encyclopedia of Philosophy, Winter 2003 ed., E. N. Zalta, Ed. [Online]. Available: [9] J. Bacon, Tropes, in The Stanford Encyclopedia of Philosophy, Fall 2002 ed., E. N. Zalta, Ed. [Online]. Available:

Lesson 10A OOP Fundamentals. By John B. Owen All rights reserved 2011, revised 2014

Lesson 10A OOP Fundamentals. By John B. Owen All rights reserved 2011, revised 2014 Lesson 10A OOP Fundamentals By John B. Owen All rights reserved 2011, revised 2014 Table of Contents Objectives Definition Pointers vs containers Object vs primitives Constructors Methods Object class