I imagine that most of the readers of this blog would claim to believe in objects (this may be true by vacuous quantification). But what does it mean to believe in objects? This has lead to a lot of reflection over the past couple of months, but in this post I want to be a little more focused. In particular, I want to ask the question of whether objects are something that we can believe in without believing in the objects of a particular kind expressed in a particular language, or if there is something more abstract about objects.

In some sense, objects are simply a way of abstracting information by joining the underlying state of the information with the code that manipulates the information. I've often said that objects are a combination of data and code, and in some abstract way that is true. But getting more detailed than this generally starts tying one to the language in which we are expressing objects.

For example, it is very rare that an object really is a combination of state and code; far more common is that an object is a combination of state and a class descriptor, with the class descriptor (often with some other form of information) pointing off to some code. There are non-class-based object-oriented languages (like Self) that don't have a notion of sharing code among a group of objects, but they are in the minority.

Once the notion of a class has been introduced, there are notions of the relationship between classes, often stated in terms of inheritance and often (but not always) associated with a type system. Different languages allow different kinds of associations to be built between classes and types. All these different ways of associating classes have an impact on the way in which the state and the code that we think of as making up the object are actually related. And then there are things like the Java language notion of a classloader, which adds another level of indirection between the state of an object and the actual code that is associated with the object.

This difference between our (or, at least, my) mental model of an object and the actual expression of an object in a computing system has all sorts of interesting effects. The only one I plan on talking about here is that an object in one language is generally very different from an object in a different language, because of all of the various ways in which different decisions made in the language design are reflected in the way the objects in that language are put together.

For example, consider an object in the Java environment and an object in C++. There are lots of surface similarities. But C++ allows multiple class inheritance, while Java does not. C++ has operator overloading, the Java language (whew!) does not. C++ objects have destructors, Java objects have finalizers; while these appear similar on the surface they are really very different. The list could go on.

Now, in what sense are Java objects the same as C++ objects? There is the conceptual similarities (both are abstractions of state, allowing polymorphic typing, etc.) but they are very hard to translate from one idiom to the other. This is something that becomes most clear when one gets asked (generally by a manager) to "translate" a program written in C++ into the Java language. Even though these two languages are both concerned with objects, there is no real sense in which one can translate a program written in one into a program written in the other; at best one can write a new program that does the same things in the new language. But this isn't translation, this is writing a new program.

In some ways, this feels similar to the situation with basic data types some time ago. When I started programming, a C int was not the same as a Pascal INTEGER and neither was anything like a COBOL PIC 9(5). In fact, at that time a C int on one machine and compiler might not be the same as a C int on a different machine or compiler. It took a lot of work to get the notion of common data types to work across programs.

Similar work has not been done in the area of objects. There has been some noise that an environment is both object-oriented and language-independent, but to my knowledge all such environments are object-oriented only in the entities that you can send messages to (either directly or across the network). The arguments and return values of those objects need to be restricted to a small number of basic data types. This is hardly allowing first-class objects in a language-independent way.

So the question that has been nagging me for the last while is simply this: is there a notion of object which is independent of the language in which one is programming? If so, I haven't come across it yet. If not, then do we have to make a choice in our work between objects and language-independence? I'm beginning to think that the second of these is the more viable approach, but it flies in the face of much of what we have been taught in software development.But perhaps that should be left as a topic for another day.