Datasheet

Here are the important features of IL:
❑ Object orientation and use of interfaces
❑ Strong distinction between value and reference types
❑ Strong data typing
❑ Error handling through the use of exceptions
❑ Use of attributes
The following sections take a closer look at each of these characteristics.
Support for Object Orientation and Interfaces
The language independence of .NET does have some practical limitations. IL is inevitably going to
implement some particular programming methodology, which means that languages targeting it are
going to have to be compatible with that methodology. The particular route that Microsoft has chosen
to follow for IL is that of classic object-oriented programming, with single implementation inheritance
of classes.
If you are unfamiliar with the concepts of object orientation, refer to Appendix A for more information.
Appendix A is posted at
www.wrox.com.
In addition to classic object-oriented programming, IL also brings in the idea of interfaces, which saw
their first implementation under Windows with COM. .NET interfaces are not the same as COM inter-
faces; they do not need to support any of the COM infrastructure (for example, they are not derived
from
IUnknown, and they do not have associated GUIDs). However, they do share with COM interfaces
the idea that they provide a contract, and classes that implement a given interface must provide imple-
mentations of the methods and properties specified by that interface.
You have now seen that working with .NET means compiling to IL, and that in turn means that you will
need to use traditional object-oriented methodologies. However, that alone is not sufficient to give you
language interoperability. After all, C++ and Java both use the same object-oriented paradigms, but they
are still not regarded as interoperable. We need to look a little more closely at the concept of language
interoperability.
To start with, we need to consider exactly what we mean by language interoperability. After all, COM
allowed components written in different languages to work together in the sense of calling each other’s
methods. What was inadequate about that? COM, by virtue of being a binary standard, did allow com-
ponents to instantiate other components and call methods or properties against them, without worrying
about the language the respective components were written in. In order to achieve this, however, each
object had to be instantiated through the COM runtime, and accessed through an interface. Depending
on the threading models of the relative components, there may have been large performance losses asso-
ciated with marshaling data between apartments or running components or both on different threads. In
the extreme case of components hosted as an executable rather than DLL files, separate processes would
need to be created in order to run them. The emphasis was very much that components could talk to
each other but only via the COM runtime. In no way with COM did components written in different lan-
guages directly communicate with each other, or instantiate instances of each other — it was always
8
Chapter 1
05_575341 ch01.qxd 10/4/05 7:03 PM Page 8