˲ If there are classes, are they also
˲ Should there be zero (for example,
Go), one (for example, Smalltalk, Java,
example, C++, Self, Simula) superclass-es or prototypes for an object?
˲ Is method lookup tied to the static
type system (if there is one)?
˲ Is the data contained within an object of static or dynamic layout?
˲ Is it possible to modify method
lookup at runtime?
The question of multiple inheritance is one of the most common areas
of focus. Single inheritance is convenient, because it simplifies many aspects of the implementation. Objects
can be extended just by appending
fields; a cast to the supertype just involves ignoring the end, and a cast to
a subtype just involves a check—the
pointer values remain the same. Downcasting in C++ requires a complex
search of the inheritance graph in the
run-time type information via a run-time library function.
In isolation, both types of inheritance are possible to implement, but
what happens if you want, for example, to expose a C++ object into Java?
You could perhaps follow the .NET or
Kaffe approach, and support direct interoperability with only a subset of C++
(Managed C++ or C++/CLI) that supports single inheritance only for classes that will be exposed on the Java side
of the barrier.
This is a good solution in general:
define a subset of one language that
maps cleanly to another but can invoke the full power of the superset.
This is the approach taken in Pragmatic Smalltalk: 5 Allow Objective-C++
objects (which can have C++ objects
as instance variables and invoke their
methods) to be exposed directly as if
they were Smalltalk objects, sharing
the same underlying representation.
This approach still provides a cognitive barrier, however. If you want to
use a C++ framework directly, such
as LLVM from Pragmatic Smalltalk or
.NET, then you will need to write single-inheritance classes that encapsulate
the multiple-inheritance classes the
library uses for most of its core types.
Another possible approach would
be to avoid exposing any fields within
the objects and just expose each C++
a massively multithreaded GPU, and a
very long instruction word (VLIW) digi-
tal signal processor (DSP). Program-
mers wanting to get the last bit of per-
formance out of the available hardware
no longer have a single language they
can use for all probable targets.
Similarly, at the other end of the
abstraction spectrum, domain-specific languages are growing more
prevalent. High-level languages typically trade generality for the ability
to represent a subset of algorithms
efficiently. More general-purpose
high-level languages such as Java
sacrifice the ability to manipulate
pointers directly in exchange for providing the programmer with a more
abstract memory model. Specialized
languages such as SQL make certain
categories of algorithms impossible
to implement but make common
tasks within their domain possible to
express in a few lines.
You can no longer expect a nontrivial application to be written in a
single language. High-level languages
typically call code written in lower-level
languages as part of their standard libraries (for example, GUI rendering),
but adding calls can be difficult.
In particular, interfaces between
two languages that are not C are often
difficult to construct. Even relatively
simple examples, such as bridging between C++ and Java, are not typically
handled automatically and require a C
interface. The Kaffe Native Interface4
did provide a mechanism for doing
this, but it was not widely adopted and
The problem of interfacing between
languages is going to become increasingly important to compiler writers
over the coming years. It presents a
number of challenges, detailed here.
object model Differences
Object-oriented languages bind some
notion of code and data together. Alan
Kay, who helped develop object-oriented programming while at Xerox PARC,
described objects as “simple computers that communicate via message
passing.” This definition leaves a lot of
leeway for different languages to fill in
˲ Should there be factory objects
(classes) as first-class constructs in the
is going to become