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 interfaces;
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 globally unique identifiers, more commonly know as GUIDs).
However, they do share with COM interfaces the idea that they provide a contract, and classes that
implement a given interface must provide implementations 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
associated 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 compo-
nents could talk to each other but only via the COM runtime. In no way with COM did components
written in different languages directly communicate with each other, or instantiate instances of each
other — it was always done with COM as an intermediary. Not only that, but the COM architecture
8
Part I: The C# Language
24727c01.qxd:WroxPro 5/7/07 12:12 PM Page 8