Key Design Goals - Page 5
April 13, 2001
The design of the CLR is based on the following goals:
- Simpler, faster development
- Automatic handling of "plumbing" such as memory management
and process communication
- Good tool support
- Scalability
Let's look at each of these in detail.
Simpler, Faster Development
A broad, consistent framework allows developers to write less,
and reuse more. Less code is possible because the system provides
a rich set of underlying functionality. Programs in .NET access
this functionality in a standard, consistent way, requiring less
"hardwiring" and customization logic to interface with these
functions than is typically needed today.
Getting Rid of Plumbing
A lot of programming infrastructure is either handled
automatically by the CLR or rendered completely unnecessary. That
is, some of it is hidden, and some of it is just not there any
more.
Memory management is an example of hidden infrastructure. Visual
Basic developers stopped worrying too much about memory long ago.
Today, C++ developers still have to, but not with the CLR, which
has memory management functions built-in (though C++ developers
have the option to do it themselves, and such unmanaged code is
in fact the default for C++). If a C++ developer chooses to take
full advantage of the CLR, it becomes unnecessary to use
CoCreateInstance, for example, to instantiate a class, or malloc
to set aside space for an array. A simple declaration statement
will do it, and the CLR allocates the memory as necessary. Then
it goes on to handle reference counting on instantiations and
automatically do garbage collection when the reference count gets
to zero.
Another example is proxies and stubs, which map interfaces on a
remote object to the local system. The proxy handles
communication with the remote object, and stands in its place
locally, so that local processes can treat the remote object as
if it were local, and the details of remote management are all
handled behind the scenes. Contrast this with the work that is
currently necessary to make DCOM work.
A lot of the missing plumbing is replaced by metadata –
standardized information about components, interfaces, and
processes that can be accessed in a consistent way. No more
cycling through IUnknown to find out how to work with an
interface – the CLR provides more flexible and much easier
to use equivalents. A later section of this chapter covers
metadata in more detail.
Tool Support
Though much of what the CLR does is similar to operating system
functionality, it is designed first and foremost to support
development languages. It furnishes a rich set of object models
that are useful to tools like designers, wizards, debuggers, and
profilers. And since the object models are at the runtime level,
such tools can be designed to work across all languages that use
the CLR. It is anticipated that third parties will produce a host
of such tools.
It's also important to note that Microsoft is not restricting use
of the CLR to Microsoft languages. Third party language vendors
are encouraged to re-architect their languages to use the CLR,
which offers a host of benefits. Besides taking advantage of all
the CLR functionality (and thereby not having to write it or
support it), using the CLR enables never before seen levels of
cross-language integration. We'll discuss more of that later in
the section on Multiple Language Support.
This capability of the CLR to work transparently with multiple
languages has some huge benefits for developers. Debuggers offer
the best example. The CLR makes it possible to write a source-
level debugger that treats all languages equally, jumping from
one language to another as necessary.
A Common Substrate for all Development - Page 4
Introducing .NET
Additional Key Design Goals - Page 6
|
