Don't Know, Do Care - A Philosopher Looks At OOP

by Steven Parker

Published 1999-02-15    Printer-friendly version

It has been my privilege and my pleasure to write about Clarion for six years. While often taxing it has earned me the sobriquet "the guy who writes Clarion for the rest of us." I wear that with great pride.

By training, however, I am a Philosopher. The creation of a new Clarion publication seems an appropriate time to "come out of the closet," wedding my vocations.

How We Got Here

Some years ago, the war cry at the Microsoft Developer's Conference was "Windows, Windows, Windows." Topspeed's rejoinder at Devcon '96 was "Templates, Templates, Templates." At Devcon '97, David A. Bayliss, in his inimitable manner, brought forth Topspeed's latest war cry, "Don't know, don't care." Because the objects in C4 handled [whatever it was that required handling], he claimed, we didn't need to concern ourselves with what was happening inside the gray box of the object (since we are supplied with the code for the classes, it really isn't quite right to call them "black boxes").

While DAB was probably overstating for the sake of making his point, most of us do care what is happening inside those objects, especially when they don't do what we want them to. It is not only a new way of thinking and doing for many of us, Topspeed's implementation is different from what we may have been expecting based on our reading.

The Received View

The almost insurmountable intellectual problem I've always had with OOP is its essential arbitrariness.

Consider this introduction to "inheritance" (from Gary Entsminger's well-received The Tao of Objects):

Once you've defined a new base type (or class), you can build on it using inheritance.... For example, if vehicle is a base class and you derive a car class from vehicle, car inherits some basic properties and behaviors from the abstract vehicle class. But there's more to a car than that....

Let's represent this system with a base object type (or class) called vehicle and derive objects called bicycle, car and boat. Any vehicle can be steered, and vehicles do different things to steer themselves ... Vehicle can respond to a message called steer, so any type that inherits vehicle can also accept that message.

Later, he uses the most apt analogy:

Another way of expressing OOP: You build family trees (or hierarchies) for data structures.... each subclass has a single immediate ancestor.

And, quite to the point, each hierarchy has a single root (root system).

Not to pick on Mr. Entsminger, his treatment is entirely typical, but "Why stop at 'vehicle'? After all, it came from somewhere; it has a 'root'." Similarly, "Why start at 'vehicle'? My app is about boats; why not start with 'boat'?" (Human beings have a unique ability to comfortably entertain entirely contradictory beliefs.)

Once you start down the slippery-slope of inheritance, there simply is no logical terminus (until you hit the fundamental building block of nature, whatever it is). If this puts you in mind of the theoretical problems that atomic theory faced in the early parts of this century and appears to be facing again, you're not far from the mark.

Yet, this is fundamental to OOP. It is the logical consequence of "inheritance." Mr. Entsminger, himself, hints at the problem: "Once you've defined." Here "you've defined" means "you have decided." And this is essentially arbitrary.

It also leads to the other side of the issue, "Why start at 'vehicle'?" Recognizing the underlying post hoc nature of the exercise (recent research indicates that "reason" simply ratifies what has already been "decided"), if your application is for boat sales, why not simply decide that "boat" is your base class? Why not indeed.

The problem with modeling real-world objects is "What is the 'root' of the hierarchy? How do you know when you've hit the primitive components?" In Philosophy, this issue was determining the essence of an object or group. What, for example, is essential to being "human?"

Plato addressed this issue. He saw all of perceived reality as combinations of 12 "Forms." By the Middle Ages, European scholars were down to four elemental parent classes: earth, fire, air and water. But by the late eighteen century, Kant had us back to 10 or 12 "Categories."

"Inheritance" and "composition," obviously, are not exactly new concepts.

Only the Bible is logically complete in addressing the underlying issue of derivation: everything is derived from God. The tetragrammaton (the four letter name of God), on the standard reading, means "I am, I will be." I.e., "The everlasting." By definition, there is no appeal beyond that which is eternal. Even if you are a non-believer, you must admit, this is the only model which satisfies the hierarchical requirement of our thinking about OOP.

So, it is no wonder that OOP was slower off the mark than journalists expected. Few, if any, took the time to analyze this, though many programmers were uncomfortable without quite knowing why (and now you do). All kinds of objects were spoken of, but "files" were never mentioned. And just how does one write business programs without files? What does the universal ("universal" they had to be since objects were to be off-the-shelf components) "student" object look like?

Too hard for you? Ok, what are the properties and methods of the (universal) "person" object? Bertram Russell answered this one. A developer of modern set theory, Russell was able to demonstrate that the set of "featherless bipeds" uniquely described humankind. While not immediately apparent to many, the absurdity of Russell's demonstration crushed the entire hierarchical approach to "essential properties" (which is also implicit in presentations of OOP) until resurrected by Chomsky and Kripke in the 60's.

The Topspeed View

The arbitrary nature of OOP is actually the core problem in Philosophy of Language.

In the 1910's, philosophers began to look at language in earnest. "How do words 'mean'?" they asked, "How do words reflect the essence of things?"

By the 40's, the "ordinary language analysis" school of Philosophy had started to claim that we all understood perfectly well what words meant. Therefore, the correct question is "What is the meaning of 'meaning'?", i.e. "How do words 'mean'?" "Essence" was side-stepped. (And the issue wasn't resolved until J.L. Austin did so in the early 60's.)

The answer lies, in part, in understanding that the denotation, the literal meaning, of words is indeed arbitrary but that the actual meaning of a word or phrase is context-dependent.

It is, I think, no small accident that the developers of Topspeed's compilers and templates are graduates of the same university where many of the great ordinary language Philosophers practiced.

It seems to me that what they've done is said "Look, we all know perfectly well what an 'object' is in the context of a (Windows) program we are writing" (this is the "art" constituent of programming).

Now, since Topspeed writes programs that assist in program writing, that context is further refined. So, they did not create objects in the sense that our reading on OOP would have lead us to expect.

Instead, they recognized that a program is a thing (i.e., an object), an object with components. Many of those components appear in different kinds of places and many can be extended in useful ways. Those components can be modeled and those are the classes Topspeed created.

Topspeed has done something literally revolutionary in the world of OOP. There is no recognizable thing from the external world, in the expected sense, modeled in the Clarion classes. What then are the classes provided? Simply: the classes we use when we use Clarion OOP are actually the building blocks of our programs.

We create windows. Thus we have a window object.

We create browses. Thus we have a browse object.

We (batch) process files. Thus we have a process object.

We work with files. Thus we have a file object.

(The file itself is not an OOP object but its handling is.)

To repeat: a program is an "object" which can be modeled in classes. The ABC classes are, by and large, just the components of a Windows program. While most proponents of OOP are busy trying to figure out how to create functional programs out of non-existent classes describing "real-world" objects, the Development Centre was busy figuring out the building blocks of a Clarion program.

Clarion OOP is just a different way of doing the same things we've been doing all along.

"A rose by any other name"

Because the most used components of a program are encapsulated in classes, you will notice some differences in how you need to code. Specifically, much of what used to be in a single long code listing is now in multiple procedure calls, you will have scoping issues and you'd best be comfortable with parameter passing; these are well documented as are the more commonly used embeds.

"'Some' differences?" you say, "Are you saying that nothing really has changed?" Substantially, this is just what I am saying and, substantially, it is true. Access:Customers.Open() does just what

IF Customers::Used = 0
  CheckOpen(Customers)
END
Customers::Used += 1

does in the Clarion templates. That is, most of the method calls you make just call procedural code in the class library (a CPU still only works one way, after all).

The big advantage is that because of this encapsulation, it is possible to extend the capabilities of the templates in ways that the procedural templates could not be extended (but that's a subject for someone who knows what they are talking about). But an obvious example is Relate:Customers.Open() which opens not only the Customers file, but all related files in a single statement.

The point, the important point, is that Clarion OOP, because Clarion is a computer programming language, takes a program as its object. If you were expecting vehicles or employees, you were looking the wrong way (you need to create those).

---

Printer-friendly version

Copyright © 1999-2009 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942