Summary
I've been thinking about objects recently. One of the questions I've been thinking about is whether or not one can make sense of objects in a language-independent way. Herein are some reflections, and what may be the start of a series of posting on the subject...

Advertisement

I've been doing some thinking about objects recently, perhaps brought on
by my agreeing to do a talk at the 8th Jini Community
Meeting on this subject. Of course, it does one good to
think hard about things that you have taken for granted for some time;
this is one of the reasons that I went back to Sun Labs some time ago, and
why I read The Mythical Man Month every couple of years, and
why I read Socrates' Apology at least as often. I, at least, need
to be reminded about the basics every now and then, and think about what I
do without thinking about it.

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.

Talk Back!

Have an opinion?
Readers have already posted
23
comments
about this weblog entry. Why not
add yours?

RSS Feed

If you'd like to be notified whenever Jim Waldo adds a new entry to his weblog, subscribe to his RSS feed.

About the Blogger

Jim Waldo is a Distinguished Engineer with Sun Microsystems, where he is the lead architect for Jini, a distributed programming system based on Java. Prior to Jini, Jim worked in JavaSoft and Sun Microsystems Laboratories, where he did research in the areas of object-oriented programming and systems, distributed computing, and user environments. Before joining Sun, Jim spent eight years at Apollo Computer and Hewlett Packard working in the areas of distributed object systems, user interfaces, class libraries, text and internationalization. While at HP, he led the design and development of the first Object Request Broker, and was instrumental in getting that technology incorporated into the first OMG CORBA specification.