Using natural language as a metaphoric base for object-oriented modeling and programming
Alistair A.R. Cockburn
Originally printed as IBM Technical Report TR-36.OO021 May 1, 1992 (with LIMITED DISTRIBUTION NOTICE This report has been submitted for publication outside of IBM and will be copyrighted if accepted for publication. )
ABSTRACT: This paper proposes natural language as a strong and intuitive metaphor to extend object oriented’s metaphor of interacting objects. We consider natural language as a metaphor rather than a programming language. The purpose is to capture the simple cognitive structures that people use to build and manipulate their models of the world, and allow programmers to use those same cognitive structures to create and manipulate program models.
Nouns and verbs are already found in the object model, but adjectives and adverbs are not. Adjectives collect subsets of classes’ functions, tell how to test whether an object is a member of a class, and why one class is a subclass of another. They provide us with simple and safe multiple and dynamic inheritance and the ability to reassign objects to classes on the fly. We also examine adverbs, relational nouns, and the genitive case.
0. Introduction
Object-oriented programming began with a strong and intuitive metaphorical base for a rather abstract activity, programming, but has become enmeshed in ad hoc technological proposals trying to fulfill and extend that base. We propose stepping back for a moment to identify another, already developed, strong and intuitive metaphor that can extend the base in directions currently giving trouble and provide a guideline for future research as well as evaluating proposed technical ideas: language.
The object-oriented model takes advantage of our natural cognitive skills, anthropomorphizing the world into a model of communicating, even self-motivated objects. In doing so, it places us directly into the language metaphor , since we naturally use a simple noun-verb pairing to describe and manipulate that model. We recognize that nouns and verbs are an essential part of any language, but it is a poor language that contains only nouns and verbs. It is with language that we classify and manipulate our understanding of the world effectively. Natural language consists, among other things, of nouns and verbs, adjectives and adverbs, grammatical rules and cases. We combine these in relatively few ways to handle an almost unlimited number of situations and concerns. For these reasons, it is worth examining natural language as the extended metaphorical base for object programming, to see what that metaphor can provide.
Why metaphorical only, why not natural language as the programming language itself? The answer is that we are looking for cognitive principles that allow people to work comfortably with the complexity of the world, and at the same time allow them to express their ideas efficiently and precisely in a programming language. Natural language contains ambiguities and affectations inherently, due to its casual development over millennia. Even though natural language has many characteristics we would wish to emulate, it may not actually make the best programming language. Object-oriented programming uses a cognitive structure close to that" of natural language, and has been demonstrated to be effective for programming tasks. It may happen that the two will one day come together. It is our choice in this paper to stay on the side of programming.
The topic being so large, we tackle only the following in this paper: we propose the metaphor of language as one that object-oriented technology ought to pursue (consider it proposed) and compare some topics currently being addressed in the technical literature with some of the topics that can be addressed through elements of language. We look more closely at adjectives, adverbs, relational nouns and the genitive case. Because adjectives are a manifestation of our classifications of the world, it becomes necessary to take a closer look at classification theory .The purpose of examining each of these topics is to identify areas in which object-oriented programming can take lessons from our use of language.
Figure 1. Schematic of some topics of current interest in OO
A chart of some current concerns in the object-oriented (OO) domain might look like Figure I. There is concern over the difference between classes and types, whether either is an adequate base for inheritance and type-checking. Inheritance is usually introduced from the concept of specialization and generalization, related to the class or type discussion. The topic of inheritance touches upon whether it should be based on shared implementation or on shared interfaces, and whether one thing may inherit from only one or more than one parent. Multiple inheritance ends up being a catch-all for many issues not comfortably settled by single inheritance, specifically, roles, relation- ships, and multi-faceted objects. Dynamic multiple inheritance is just beginning to emerge as a topic.
While Figure 1 is not an exhaustive chart of the issues, it certainly illustrates why these issues are exhausting. Figure 2 is a result of looking at some of these topics in the light of natural language and basic classification theory . It shows, among other things: classification has (at least) two separate sides, specialization and facet subclassification; role is a term covering two quite different concepts, impersonation and relationships; some relationships are modeled as nouns (relational nouns); multiple inheritance is being assigned to handle issues from diverse sources. Finally, adverbs have some role to play in the development of polymorphism.
Figure 2. Schematic of topics covered in this paper .
The topics in the paper crisscross each other just as Figure 2 does. Figure 2, then, will serve as our table of con- tents. After rust reviewing related work, we traverse the figure as follows: We rust spend time on adjectives and classification theory , as they introduce the idea of capturing essential properties and safely being able to determine and reassign objects’ classifications at compile- and run-time. We look very closely at specialization hierarchies, because they are typically not implemented in their natural form, and the results of the preceding section can be brought to bear. We then take a look at relationship-bearing-nouns (relational nouns) and the two definitions of role, impersonation and relationship, and their relation to dynamic assignment of properties. The genitive case is discussed with respect to traversing networks of relationships. Finally, we discuss the relation of adverbs to soft- ware structuring and polymorphism.
One topic we avoid is the class/type discussion. In this paper we use the word c/ass throughout, even when type might be considered more appropriate. The reason is that we use class as coming from classification. Typing is one way of using information resulting from classification activities. Class in the OO language sense has to do with code sharing and is another use of classification information. There is a third use of class coming from biological taxonomy, which is an even more specific use of the word and has little to do with general classification. We shall try to be clear about the meaning of the word class in different contexts. In general, we mean class as a result of classification.
Before moving on, we review briefly the elementary noun-verb language offered by the OO model. It is simply this: the objects or data being manipulated become nouns, and the functions associated with those objects become verbs. A common way to call out an object’s function is write a noun followed by a verb. Thus, invocation of a conversion routine from an internally formatted date to a sequence of Roman numerals might (verbosely) be coded as,
“heyYouDate renderYourse1fAsRomanNumerals”. If the function has more than two operands the language metaphor breaks down (e.g. “time secondsSince ( 5/2/92, 1/1/80 ) or “time inSeconds: 5/5/92 since: 1/1/80”). The Vivarium project 15 reports progress in moving to phrasal languages, which incorporate prepositions as parameter separators
1. Related work
Minsky and Rozeheim propose “A law-based approach to object-oriented programming” 23, in which they suggest another metaphorical base for OO activity, that of the regulatory model of law. It is interesting to consider, given our opening remarks, that law is an example of programming with natural language. Nonetheless, the structure of the law is not based on the structure of language, and so these two two metaphorical models have little overlap. The two metaphors may well find a way to complement each other.
The “mixin” 11 is a metaphor coming from the ice-cream parlor: mixing toppings on an ice-cream sundae. The metaphor is that when you combine several toppings, you get all the properties of each, and you ought not combine them if you only want some of the properties of each (unlike the way in which some programmers have tended to combined properties of classes). The advice is sound, but the metaphor is neither as strong nor as intuitive as it needs to be. It has not yet been adopted up by the OO programming community at large, nor by OO modelers. The mixin operator introduced by Bracha and Cook 2 combines subsets of interfaces in much the same way as do adjectives. Presumably, if the defining properties of classes were stored with the classes, the mixin operator would combine them appropriately.
Many authors are advocating and wrestling with multiple inheritance 4 11 18 22 and particularly the issue of typing 1 20 25. Three things are at stake here: (1) efficient polymorphic linkages, (2) ease of program construction, (3) the safety of the program during execution. Whereas we ignore the first issue in this paper, we care about the other two. As do many of these authors, we conclude that multiple inheritance is a basic necessity (we conclude it on cognitive grounds), but we deplore the engineering difficulties caused by current multiple inheritance systems. What we are after is a safe and intuitive way to combine concepts.
Odell 21 24 identifies the need for multiple and dynamic classification. His motivation is from the point of view of an analyst examining previous work in logic and data modeling. Odell does not fit his recommendations into a metaphorical framework, but he makes some of the same recommendations, also is motivated by the desire to reduce cognitive dissonance, and even populates his arguments with references to natural language.
Many authors reference parts of speech in illustrating their methods without seeming to notice 8 13 28 29. It may be they have not identified where the ideas are originating, or they just have not dared to commit to the metaphor.
Nonetheless, a piece of advice coming from teachers of OO techniques is: underline the nouns and adjectives (consider them for classes), underline the verbs (consider them for operations), and underline the participles (consider them for subclasses and trigger events). These authors and these teachers have laid a base for our formally pro- posing the metaphor .
No theory of faceted classification shows up in the OO literature, but several authors introduce related ideas: views 5 30; using subsets of a class’s interface as types 8 13; being able to inherit protocol declarations 29. A view is closest, as it captures a subset of the interface offered by a class of objects much as an adjective does. Carre and Geib offer the tantalizing prospect that “An object can be a direct member of several classes, and this, dynamically”. That is exactly where we believe OO languages ought to and will go in the future.
For information on classification theory, the texts of Lakoff16, Rosch and Lloyd 26 12, and Smith and Medin 32 are excellent. A good description of the differences between features and dimensions is found in Rosch and Lloyd (pp.75, 102) and Smith and Medin (pp.l5-l7). All of these authors, but Lakoff in particular, take classification much farther than we do, and show the limitations of the “traditional” treatment of classification (which we still use in this paper). They offer a different cognitive structure for modeling the world, based on prototypical models and chained associations leading outward. Those concepts are far enough from the the current state of OO that we leave them as future research and simply point to the issue for other researchers.
2. Adjectives and Classification
2.1. Adjectives
The adjective is blandly defined in Webster’s as "A word used to describe a noun or limit its meaning" 36. Even this short definition has two parts, (I) describing a noun and (2) limiting a noun’s meaning. We use (I) to motivate documenting the essential property, or "why" of a class, and (I) and (2) to look for the capability for impromptu but safe mixing of classes.
In OO programming, the most obvious function of an adjective is carried by the state variables of an object, which at once describe the noun and limit its meaning. “Betty is six-foot woman” refers to an object of class ‘Woman" having a state variable "Height" with value 182.88 (centimeters, naturally). "Anton is a male nurse with red hair" is captured as: class = "Nurse", Sex = "male", Hair-color= "red". An adjective modifying a particular noun corresponds to assigning values to corresponding object’s state variables. In this simple usage, adjectives just give us an alternate syntax for the assignment of values to state variables, a syntax that mayor may not be superior to any other one, and hence hardly motivates their use.
When the noun defines a class of objects, however, the adjective’s presence produces a subset of that class (a sub- class). The subclass is either a pure specialization of the class (a "symmetric ellipse" is a specialization of ellipse) or identifies a "facet" of the superclass (an "aquatic vehicle" is a vehicle viewed with respect to water, an "introduced" concept). In both cases the adjective limits the meaning of the noun and describes it.
What does it mean to say an adjective "describes" a noun? Basically, it gives us a test of the object’s membership in a class. We refer to this test as the why of the subclass, and suggest that OO languages ought to capture the why of subclassing. The why and the test of subclassing are not preserved in current OO programming or even in OO modeling. In current form, the class hierarchy discloses only that one class is a subclass of another, not why. Even in entity-relationship modeling28 all of subclassing is a single relation: IS_A (or SUBTYPE). The absence of the why information causes difficulties, as we shall see.
2.2. Classification
Classifying a concept into narrower concepts is done through a membership relation, a test for membership in the class. The test is usually defined to be one that yields a "yes" or "no" answer14. The class "symmetric ellipse" uses a relation on the two axes, "major= minor", and the test is simply, "are the axes equal?" In practice, a test may be chosen that bundles a whole set of yes/no questions into a single, fill-in-the-blank question; the assumption is made that a simple, meaningful answer can be given. Thus, the class "aquatic vehicle" may be based on a "yes" answer to the question "does it traverse water?", or, on the presupposition that every vehicle traverses some medium, it may be based on the answer "water" to the question, "what medium does it traverse?” In this paper we adopt the latter, more general form of question.
Two rather different kinds of relations, or membership tests, can be found. In the first, only components of the base concept are tested in the relation. We call these specializations. The amount of information needed to characterize an instance of a specialized subclass is less than for the superclass, because the relation itself provides some of the required information. In the example of circle being an ellipse with equal-sized major and minor axes, the circle needs only one axis value to be to be fully characterized, the ellipse needs two.
The second kind of membership test is a test between the base concept and another, introduced, concept. We call the introduced concept a "facet". In the example of "aquatic vehicle", the facet is either "water" ("does it traverse water?") or "medium" ("what medium does it traverse?" -the value of the facet is "water"). We call this second type .of membership test facet subclassification. We observe that there is considerable freedom in choosing the classification question and hence the facet or facet value..
In common classification terminology , a distinction is made between facets that are continuous and those that are enumerated. A facet providing a continuum of comparable values12, such as height, is called a dimension. If the facet is enumerated, it is said to contain features. The issue of feature vs. dimension, although described in the classification literature, is not very carefully laid out. Note that the two terms are not actually comparable: a dimension is a set of values, whereas a feature is a member of a set of values26 32.. Nor is it stated what happens with discrete, infinite sets, or even to what extent it matters. We can suppose that the freedom in structuring the defining relation makes the distinction between feature and dimension interesting but not crucial (for example, a color may be defined either as a selection from an enumerated set of color names or from a continuous set of wavelengths). For these reasons, we do not pursue the difference between feature and dimension, but simply say that a facet is a concept introduced by the defining relation.
A concept can have any number of facets, because it may be tested against any number of other concepts or even itself. Every instance of the concept has every facet, since every instance participates in every test. Of course, not all facets are of equal interest. In practice, a facet is introduced as soon as the relationship to the new concept becomes relevant. Facet subclassification, unlike specialization, increases the amount of information needed to characterize the object, because of the reference to the new concept.
To illustrate how additional concepts are introduced in common practice, imagine the characterization of a "vehicle". Suppose for a moment that being a "vehicle" requires only that an object transport things from one space/time location to another. With "aquatic vehicle", we introduce the concept of water. We could as easily have introduced another medium ("air vehicle"), or a power source ("human-powered vehicle"), or the vehicle’s structure ("enclosed vehicle"), or any combination thereof ("enclosed, human-powered, land and air vehicle" -the Gossamer Condor, perhaps?). Notice how easily in ordinary language we combine adjectives to create subclasses with the desired characteristics. We regard it as a goal of OO programming to be able ~o do the same with program objects.
A major difference between OO practitioners and other taxonomers is that in OO one does not record the taxonomic basis, normally considered essential:
"the specification of a classificatory system requires a corresponding set of classificatory concepts …these requirements call for ( 1) a clear specification of the basic concepts used to represent the theoretical entities …(2) a set of theoretical assumptions …asserting certain interrelations among the corresponding theoretical entities; (3) an empirical interpretation of the theory …connecting the theoretical traits, states, or processes with observable phenomena; (4) testability-in-principle of the theory… the establishment of a suitable system of classification in a given domain of investigation may be considered as a special kind of scientific concept formation."14
OO modelers and programmers need a way to both identify and use the why information of a class hierarchy. At the moment, all they are given is a single, binary relation, “()IS_A()”. Specialization requires a 3-way relation, “(z)isSubsetOf(y)because(x)”, and facet subclassification uses a 4-way relation, “(z)isSubsetOf(y)because(x)withRespectTo(w)”. Once identified, the why information must be connected with a test for membership. Class-membership testing is an essential step in providing for safe and rich mixing of class properties.
2.3. Efficient Implementation of Specialization Hierarchies
Oddly enough, given the strong tie of OO to real-world modeling, specialization hierarchies are frequently not implemented as modeled. Implementors rearrange the original, specification hierarchy on grounds of engineering efficiency and program safety: (1) current rules of inheritance utilize storage inefficiently to a degree that might cripple an application; (2) invoking commands inherited from the superclass may violate the integrity of the specialized class. This restructuring of hierarchies creates problems: (l) the system structure is more difficult to learn; (2) implementers end up working with a different system structure than the specifiers, which introduces communication hardships and possibly structure translation errors; (3) extra functions must be written to provide conversion between ostensibly compatible types; and (4) there is less stability in the implementation hierarchy, since it is based on local opportunities and costs.
For discussion, consider two natural and simple specialization hierarchies: a point is a special (zero-radius) circle, which is a special (symmetric) ellipse, which is a special (quadratic) superellipse; an integer is a special real number (zero fractional part), and areal number is a special complex number (zero imaginary part). To most people, mathematicians and lay, both of these hierarchies are reasonable, useful and intuitive. Neither is sensible for imple- mentation in current OO systems, however, because current OO languages are based on the following inheritance rule:
A class inherits all state variables and procedures of its superclasses
The state variables are the first problem here. In the ellipse hierarchy, every circle carries one useless axis variable, and every point is forced to carry a pair of variables for its major and minor axes, all known to be zero. In the second, every integer carries as useless baggage zero-valued fractional and imaginary variables. These are so inefficient that they are not seriously considered for implementation. Typically, instead, the classes may be made peers in the hierarchy, or parts of the hierarchy may actually be inverted, and extra functions are written to simulate the original hierarchy: e.g., a circle is asked to create an equivalent ellipse, an integer is asked to create an equivalent real, a real to create an equivalent complex, etc. In addition to the burden of extra code, there is an additional burden learning the class hierarchy. Should local implementation constraints change, it is quite possible that the implementation class hierarchy will change to suit. The current situation is clearly neither desirable nor particularly advantageous.
If automatic inheritance of state variables is all that is in the way, can we propose a different inheritance rule, one that does not require state variables to be inherited? Suppose,
A class inherits all procedures, but not necessarily all state variables of its superclasses.
This is still not satisfactory .A superclass command may require a change to a state variable not possessed by the subclass. In normal life, we accept that certain commands may not hold in the case of specialization. An ellipse may be elongated so that one axis is twice the size of the other, but a circle may not. This does not disturb us, because we understand that the specialization creates a subclass to which the command "elongate" does not apply.
Some authors insist that it is a fundamental characteristic of "type", "supertype", and "subtype" that subtypes be fully substitutable for supertypes19. We have just seen that, based on human-cognition, a subclass (in the classification sense) is not universally substitutable for its superclasses. This does not mean that the statements requiring type-substitutability are incorrect; it does suggest that they are defined on some other base, possibly a set of unstated mathematical axioms, possibly just the intuition of the author.
A program object may be provided with a state variable simply because some details of the object are unknown. Thus a "person" object may be provided with a variable, "sex". Even today, a person’s sex is not as easily altered as hair length, so the existence of the variable probably does not mean "can vary". Normally, when a person has a sex change we reclassify them. In a corresponding way, we should want for an object to be reclassified based upon the new state of its variables and the essential properties of the classes.
Of all an object’s procedures, some do not cause a change in the object’s state. These we call queries, and the rest commands. The strongest defensible inheritance rule we have found is:
A class must be able to answer any query answerable by its superclasses.
According to this inheritance rule, a class need not inherit all commands and state variables of its superclass(es). Indeed, state variables become an issue private to a class’s implementation, which is as it should be. When a state variable is eliminated, it will be replaced by some kind of code, which should then become part of the class’s defining characteristic. Its ideal form would be as a constraint, something that can be used to produce class conformance at object-creation time and to check for conformance any time later on. In the case of circles, the constraint is "minor = major", a constraint that can be used to eliminate one of the two axis variables of ellipse and test any ellipse for circle-membership.
In summary, an adjective collects the essential properties, the why, of a concept or classification, giving it a name. People are used to being able to ask what an adjective means and to use that information to learn about the prop- erties of an object or test it for validity. We expect the same abilities in OO modeling and programming.
3. Relational Nouns and Roles
A class may be given the name of its characterizing relationship. One example is "employee": an employee is an "employed person", i.e., a person employed by an individual or company. In using the adjective as a noun, we really are describing one end of a relationship: the role of the object with respect to the object at another end of the relationship. Such a noun could be called "relationship-as-noun" or "adjective-become-noun". We call them "relational nouns". Oddly enough, given their significance in data modeling, they seem to deserve no special term in business writing3. Before examining relational nouns in detail, we need to take a closer look at the word role, and its use in programming.
3.1. Roles
Webster gives role several definitions: "a character assigned or assumed …a socially expected behavior pattern … an identifier attached to an index term to show functional relationships between terms"36. We distinguish the 3 parts to this definition: (I) assignment of sets of properties, (2) a single, defined set of behavior, and (3) one end of a relationship.
In programming, part (1) corresponds to assigning a set of functions. Assigning them at object-creation time is rather obvious, so we concentrate on dynamic assignment. In rea11ife, we use this first sense of the word role to describe a form of impersonation (impersonate = "pretend to be"36) in which one object functions as another for a period of time. Example: a doorstop is triangular and jams under a door; some staple removers are triangular enough and small enough to be pressed into service as a doorstop. In similar extreme circumstances forks have been used as hammers. The staple remover take the role of a doorstop, and the fork takes the role of a hammer.
It is easy to see that this capability, "what is known to be needed is not available, but something may be made to impersonate it", would be useful in an artificial intelligence program. However, it may also prove useful in DP programs, such as in a system that scavenges old programs for reuse in new settings. The capability we are talking about is the one introduced in section 2, namely, the ability to ask a class for its essential properties, discover an object that has those properties, and then assign the necessary portion of the class’s protocol to the object, i.e., to capture and use a class’s essential properties.
Part (2) of the definition just clarifies: a role is a defined set of behavior, i.e., a set of functions. A word that identifies a role identifies a set of protocol that applies whenever the role is attached to an object (compare Carre’s “views” 5 and Harrison’s “types” 13).
Part (3) moves us forward to relationships and relational nouns. For our purposes, this use of role is more effectively expressed by Rumbaugh et. al:
" A role is one end of an association. A binary association has two roles, each of which may have a role name. A role name is a name that uniquely identifies one end of an association …Roles often appear as nouns in problem descriptions."28
3.2. Relational nouns and program construction Relational nouns are "adjective become nouns", or "relationships as nouns", nouns like as "employee", "employer", "secretary", "father", ‘1lusband". Since they represent one end of a relationship, they beg for a connecting preposi- tion ("secretary to", "father of’), which may be satisfied by a genitive-case noun acting as an adjective (’1ler father", "the President’s secretary"). Although no distinction is made in business writing for nouns formed from a relationship3, it is considered important in data modeling9 13 27 31 33, as it affects the consistency and form of persistent and shared data28. For object-oriented systems, there are two important characteristics of a relational noun: (I) the existence of the object depends upon the existence of the objects it relates, and (2) objects may share multiple such relationships. Example: a "pet" exists only if both the animal and owner exist; no animal is a pet in and of itself33, an "employee" implies the existence of an "employer". A pair < individual, company > may be related in several ways, such as < employee, employer > and as < customer, vendor > .Note that these relationships are most accurately identified by naming both ends of the relationship9 21 34 A relational noun comes into being when two (or more) objects fulfill a defmed relationship with each other (this is almost identical to the defmition of facet subclassification in Section 2.2). The newly related objects pick up addi- tional properties as defmed by the adjective naming the relationship. In short, they fulfill the requirements of new subclasses. However, unlike the static subclasses of earlier sections, these relationships may be fulfilled and broken numerous times within the lifetimes of the related objects. The base objects need to be able to gain and lose sets of properties repeatedly. To model relationships successfully, our programming environment must able to follow the effects of adding and dropping sets of properties. It must be able to detect and assign sets of properties to objects during program execution, based upon characteristics of the objects’ state variables. The fact that objects may participate in more than one relationship requires some care in program design. In some discussions in the literature, a relational noun is modeled directly as a specialization of the object being modified by the adjective6, which embroils the modeler in the single-inheritance / multiple-inheritance controversy at a very early stage of modeling. It is possible, through attentive modeling, to defer that decision until the appropriate implementation issues are raised28 31 3.3. Genitive Case
The genitive case is defined by Webster as "marking typically a relatively close, unchanging, and exclusive relation- ship such as that of possessor or source" or "expressing a relationship that in some inflected languages is often marked by a genitive case -used esp. of English prepositional phrases introduced by OF" 35. There is not much new to say about the genitive case, since it is already well handled by mathematics and programming. Therefore, we just briefly summarize the topics covered by the genitive case and its appearance in programming.
The genitive is used to traverse networks of relationships. One such relationship is "part of’. A pedal is part of a bicycle, so we say "the pedal of the bicycle" or "the bicycle’s pedal". However, the genitive covers other relation- ships, and can be chained to traverse as many stages of the network as required: "the bus’ driver’s wife’s coat’s collar" (all one word in German).
Programming languages in general are good at traversing networks of relationships, because traversing function networks can be done by composing functions (e.g., f(g(x))). OO programming is no exception, with one catch: bidirectional relations are not automatically maintained by current OO systems, even when they have been modeled. Bidirectional consistency has to be maintained by the programmer, which creates a programming hazard. As a result, bidirectional relationships are often avoided in the interest of program safety, making a relationship easy to traverse in one direction but not the other. It is not important to this paper how it is done, but it is a consequence of the language model that once the modeler defines a relationship, the programmer should be able to traverse that relationship equally easily in both directions.
4. Adjectives, Dynamic Properties and Multiple Inheritance
‘Once the essential properties of a subclass are captured in executable form, properties of an object can be tested, augmented or reduced in reasonable and controlled ways during execution, mirroring the way we use adjectives in everyday speech.
If an object has, even momentarily, the essential properties of a class, then we should be able to process it as an instance of that class; the operations of the class are known to be safe on that object. This applies even if the property is satisfied only coincidentally (the bread happens to be hard enough to serve as a hammer, the complex number happens to be an integer, the ellipse happens to be a circle, the fence happens to resemble a ladder, etc.). Should the property cease to hold, the object also loses the operations of the class. This fits our everyday experiences of life and our uses of language, and not coincidentally is is beginning to attract the attention of the research community 8 13 21
In natural language usage, new classes can also be created impromptu, without a “system programmer” having to enter them in a master class library .The issue is really the same: properties are sets of functions, and they are attached to objects via adjectives. In the former case the adjectives were applied to individual objects, in this case the adjectives are applied to classes to create subclasses.
Two examples of impromptu classes are “edible paper” and “elliptical, scrolling windows”. In the first case we endow a category of paper with functions associated with food, such as nutritional value and taste. In the second case, we may know that a window is associated with some closed, convex shape without knowing which. During execution, the shape is determined, and the functions of the shape become associated with the window.
These examples all use multiple inheritance, a simpler and more powerful multiple inheritance than is available today. All operations can be made safe and general, because the critical properties can be checked on demand.
5. Adverbs
Adverb: "typically serving as a modifier of a verb, an adjective, another adverb, a preposition, a phrase, a clause, or a sentence, and expressing some relation of manner or quality, place, time, degree, number, cause opposition, affirmation, or denial" 35. Adverbs first .appear in programming as function parameters. They are either passed on to another function or used to select between sub-functions. Of the two cases, only the second is interesting here, because of its relation to polymorphism.
One of the benefits of polymorphism is that it allows a programmer to divide a function into small, single-minded functions, relatively less error-prone, easier to understand, and easier to reuse. The compiler or run-time system selects one of the functions as appropriate based on some criterion. The only criterion supported today is the class name of one or more parameters, but it is not the only or best criterion. Natural language uses several selection mechanisms to indicate which interpretation of the verb is intended, first by the meaning of the noun to which it is attached, and second, by the adverbs applied to it (e.g., “compute this quickly”, or “compute this (space-)efficiently”).
Adverbs have defined meanings just as adjectives do (i.e., computable functions operating on the characteristics of their verbs). To realize the capability of adverbs, polymorphic selection will have to be generalized to operate from any computable function. There is, of course, the speed efficiency to consider in using arbitrary functions as polymorphic selectors, but that should be a design constraint and not an impossibility. What if more than one of the polymorphic functions passes the test for execution? The answer ought to be that any of them may be selected, for just as in any activity, once we have specified what is to be done at an appropriate level of granularity, all of the other considerations may be considered “don’t care.” It is the responsibility of the analyst/designer/programmer to ensure that any selected function produces a valid response.
Adverbs are a bundling of adjectives just as adjectives are a bundling of relations. It is beyond the scope of this paper to detail the application of this capability, but an example of its use is in the passing of a collection of parameters as function arguments, as in the phrase, “an enormous man with a correspondingly dimensioned wardrobe”.
6. Future Work
1. This paper did not produce a formal model reducing adjectives, adverbs and relations to nouns and verbs. We have seen that adverbs reduce to adjectives or sets of relations, and that adjectives reduce to sets of relations, and relations to functions (verbs) applied to nouns. This was done informally, to point to the power that is available through the metaphor. It is still necessary to formalize the reductio, in order to put the mechanisms of essential properties and dynamic property assignment on a mathematical foundation.
2. Other parts of speech and other tenses are waiting to be decoded. The past participle ("shipped product", "aborted transaction") is an indicator of changed state, and can be used to define a trigger process dependent on that change or a new subclass with that property 2l. The collective noun ("jury", "senate") is another linguistic construct, which may be developed to extend the notion of class and subclass to all collections.
3. This paper used only the most basic and traditional classification theory. A person’s use of adjectives and adverbs is much more sophisticated than we have described. Cognitive linguists and psychologists have made progress in understanding the mechanisms involved16. Our next steps involve capturing additional cognitive mechanisms to be incorporated into "computational rhetoric". In addition to more sophisticated classification schemes, entirely other cognitive mechanisms, such as "metonymy" (generalization from a single example to an entire class7 16) are waiting to be harnessed.
7. Conclusion
Natural language does indeed look promising as an extended metaphor for the object-oriented paradigm It is extremely powerful, simple, and has a good natural match with people’s capabilities.
Adjectives provide a model for capturing and evaluating essential properties of classes, allowing for safe assignment of classes’ properties at compile and run time, singly or in combinations. Adverbs are functions on properties of sets of functions, and generalize polymorphism to function selection based upon evaluation of arbitrary computable functions. The genitive case is used to traverse networks of relations. The symmetry of the genitive points to a need for bidirectional relation traversal.
Tied to our use of adjectives and adverbs is classification; understanding of classification theory is significantly ahead of the programming community’s ability to harness it. Classification, metonymy, and language are three of the powerful cognitive mechanisms people use daily that we can look forward to using in programming.
Acknowledgements
Jack Goodyear pointed out that the relations attached to relational nouns are really adjectives, and provided many tips on language. Discussions with Wayne Stevens brought several issues into sharper focus, and Dick Antalek asked ‘Why?" to everything, echoing a theme of this paper, improving its contents, and making our conversations very long.
References
1 - Agrawal, R, OeMichiel, L, Lindsay, B., "Static type checking of multi-methods", OOPSLA ‘91, SIGPLAN Notices 26(11), Nov. 91, pp.113-128.
2 - Bracha, G., Cook, W., "Mixin-based inheritance, OOPSLA/ECOOP ‘90, SIGPLAN Notices 25(10), Oct. 90, pp.303-311.
3 - Brusaw, C., Aired, G., Oliu, W., "The Business Writer’s Handbook", St. Martins Press, NY, 1976.
4 - Canning, P., Cook, W., Hill, W., 01thoff, W., "Interfaces for strongly-typed object-oriented programming", OOPSLA ‘89, SIGPLAN Notices 24(10), Oct. 90.
5 - Carre, B, Geib, J-M., "The point of view notion for multiple-inheritance", OOPSLA/ECOOP ‘90, SIGPLAN Notices 25(10), Oct. 90, pp.312-321.
6 - Coad, P., Yourdon, E., "Object-Oriented Ananlysis", Yourdon Press, Englwood Cliffs, NJ, 1991
7 - Cockburn, A., Citrin, W., Hauser, R., von Kanel, J., "Using formalized temporal message-flow diagrams", IBM research report, to appear, 1992.
8 - DeNatale, R., "Types from the clients’ viewpoint", IBM TR 29.1246. IBM Corp, Cary, NC., 1991
9 - Detroyer, 0., ‘The OO-binary relationship model: a truly object oriented conceptual model", IBM TR 29.1246. IBM Corp, Cary, NC., 1991
10 - Fenton, J, Beck, K., "Playground: an OO simulation system with agent rules for children of all ages", OOPSLA ‘89, SIGPLAN Notices 24(10), Oct. 89, pp.140-150.
11 - Gabrial, R., White, J., Bobrow, D., "CLOS: integrating object-oriented and functional programming", Cornrnunications of the ACM 34(9) Sept. 91, pp.28-39.
12 - Garner, W., "Aspects of a stimulus: features, dimensions and configurations", in "Cognition and Cat- egorization", Lawrence Erlbaum Association Publ., Hillsdale NJ, 1978, p.102. Harrison, W., "The 0+ R model", IBM Research Report RC 17499, 1991.
14 - Hempel, C., "Fundamentals of taxonomy", in " Aspects of Scientific Explanation and Other Essays in the Philosophy of Science", The Free Press, N.Y., 1965, pp.137-154.
15 - Ingalls, D, Wallace, S, Chow, Y-Y, Ludolph, F., Doyle, K., "Fabrik: a visual programming environment", OOPSLA ‘88, SIGPLAN Notices 23(11), Nov. 88, pp.176-190.
16 - Lakoff, G., ‘Women, Fire, and Dangerous Things", University of Chicago Press, Chicago, 1987.
17 - Levi-Strauss, C., "The Savage Mind", University of Chicago Press, Chicago, 1962.
18 - Lieberherr, K., Xiao, C., Silva-Lepe, I., "Graph-based propagation for object-oriented programming", TR NU-CCS-91-14, Northeastern University, Boston, MA, 1991
19 - Liskov, B., "Data abstraction and inheritance", OOPSLA ‘87 Addendum, SIGPLAN Notices 23(5), May, 88, pp.17-34.
20 - Madsen, 0, Magnusson, B, Moelier-Pedersen, B., "Strong typing of object-oriented languages revisited", OOPSLA/ECOOP ‘90, SIGPLAN Notices 25(10), Oct. 90, pp.140-145.
21 - Martin, J., Odeli, J., "Object-oriented Analysis and Design", Prentice-Hall, New York, NY, 1992.
22 - Meyer, B., "Object-oriented Software Construction", Prentice-Hall, New York, NY, 1988.
23 - Minsky, N., Rozenheim, D., "A law-based approach to object-oriented programming", OOPSLA ‘87, SIGPLAN Notices 22(12), Dec. 87, pp.482+ .
24 - Odell, J., "Multiple and dynamic classification", Journal of Object-Oriented Programming, Jan ‘92.
25 - Palsberg, J., Schwatzbach, M., "Type substitution for object-oriented programming", OOPSLA/ECOOP ‘90, SIGPLAN Notices 25(10), Oct. 90, pp.140-150.
26 - Rosch, E., Lloyd, B., eds., "Cognition and Categorization", Lawrence Erlbaum Association Publ., Hillsdale NJ, 1978.
27- Rumbaugh, J., "Relations as semantic constructs in an OO language", OOPSLA ‘87, SIGPLAN Notices 22(12), Dec. 87, pp.466-481.
28 - Rumbaugh, J, Blaha, M., Premerlani, W., Eddy, F., Lorensen, W., "Object-oriented modeling and design", Prentice-Hall, Englewood Cliffs, NJ 1991.
29 - Sandberg, D., NAn alternative to subclassing", OOPSLA ‘86, SIGPLAN Notices 21(11), Nov. 86, pp.424-428.
30 - Schilling, J., Sweeney, P.,. "Three steps to views: extending the OO paradigm", OOPSLA ‘89, SIGPLAN Notices 24(10), Oct. 90, pp.353-361.
31 - Shlaer, S., Melior, S., “Object-oriented systems analysis”, Yourdon Press, Englewood Cliffs, NJ 1988.
32 - Smith, E., Medin, D., "Categories and Concepts", Harvard University Press, Cambridge, MA, 1981.
33 - Sowa, J ., "Conceptual Graphs", IBM report, forthcoming.
34 - Tsichritzis, D., Lochovsky, F., HData Models", Prentice-Hall, Englewood Cliffs, NJ 1982
35 - Webster’s Third New International Dictionary, Encyclopaedia Britannica, Inc., Chicago, IL, 1976
36 - Webster’s New Collegiate Dictionary, G. & C. Merriam Co.,Springfield, ~1A, 1977.
Posted in Education & Reference |
Aligarh City:
-18 °c
