A Historical Perspective


The idea of a runtime library is certainly not a new one to the computing industry. The .NET Framework is built on an extensive history of programming systems, but it provides a unique blend of features and some evolutionary developments that extend traditional computing concepts. This section cannot hope to provide a complete list of the programming systems that form the historical basis for the .NET Framework, nor can it fully explore the list of contributions from each system. Rather, by comparing and contrasting the various language systems, it seeks to highlight the key features of the .NET Framework.

C/C++

With the introduction of the C programming language in 1972, the notion of a standard library that ported to different computing architectures emerged as a popular concept. For example, the C library includes standard I/O functions (in the stdio header and library file) that define how to handle input and output to files and the console. The .NET Framework provides a similar set of functions that often work in a similar way, but has an object-oriented design that provides a higher level of abstraction. The framework defines an inheritance hierarchy to represent streams (including a concrete class to represent random access to a file), whereas the C standard library represents a file with an integer file handle.

The C language's successor, C++, offers similar concepts to the BCL in its iostream library.

SmallTalk

Around the same time that the C programming language was introduced, SmallTalk popularized the notion of a unified type system wherein every type in the system has a single base type from which all types are derived. This unification adds elegance to the SmallTalk library. Any item can be stored or accessed via this common base type. For example, any type can be stored in a collection directly without the use of intermediate wrapping. Unfortunately, this unification comes at a price to performance, because it turns all types into reference types. Doing even simple integer arithmetic can generate a large amount of transient memory usage on the heap that needs to be managed. (Such transient memory is often called garbage. )

The .NET Framework also supports this notion of a unified type system, but does so in such a way that primitive types are allocated on a stack (as in C/C++) when used specifically and allocated on a managed heap when they are used generically (as in SmallTalk). This approach allows the .NET Framework to achieve the same level of elegance as the SmallTalk library without necessarily incurring the performance penalty associated with it. Naturally, a trade-off is required with the CLR's type system: Moving data between the stack and the heap could degrade performance in some cases.

LISP

As early as 1959, LISP popularized the use of automatic memory management (garbage collection), which avoids many of the programming problems that frequently crop up in C/C++ programs. This automatic memory management feature allows the standard library in LISP to follow more of a functional programming model in which it is common to create temporary objects to cleanly express an operation. The Framework Class Library also benefits from a garbage collection system, which adds a functional programming flavor to a basically object-oriented system.

C++

The Base Framework has an object-oriented design that was popularized by SmallTalk, Eiffel, and C++ in the late 1980s and early 1990s. Object-oriented design allows functionality to be encapsulated as classes and operations on those classes. Libraries can then leverage this functionality to produce rich inheritance hierarchies that enable meaningful reuse of code. In contrast, because C++ retains many low-level operations of the C language, such as pointer manipulation, unsafe casts, and so forth, it is extremely difficult to use C++ to write applications that need to run in semi-trusted environments (such as code downloaded from the Internet or user code running in a SQL or Web server).

Java

Targeted to respond to the increasing use of the Internet, around 1995 Java became one of the first languages to introduce the idea of semi-trusted execution. Java is an object-oriented language that provides a substantial class library. It enables applications downloaded from the Internet to run in a "sand-box" where they can access only a small amount of system resources (screen real estate, network access, and file system access). Libraries control these resources, employing permissions to protect them. The .NET Framework uses a similar mechanism to protect resources. It brings forward many ideas from C++ that Java does not, however. For example, user-defined, stack-allocated primitive types (structures) and operator overloading allow extension of the base type system; users can add their own base types that fit right into the system. Enumerations allow for much cleaner, self-documenting API design. Also unlike Java, the .NET Framework offers built-in support for component design such as properties and events.

Support for Multiple Programming Languages

In the past, many attempts have been made to build systems that support multiple programming languages. Most notably, COM provided support for early-bound languages such as C and C++ as well as late-bound languages such Visual Basic and Script. It accomplished this goal by requiring each type to support different interfaces for the various languages. That is, COM types need to support custom interfaces for C/C++ as well as IDispatch for Visual Basic and Scripting languages. This split in the model meant that some functionality was exposed to only some developers but not to others, because library developers had to do extra work to target each group . On the other hand, CORBA objects do not know, or care, if their clients use early or late binding when invoking methods . This is also the situation for the CLR.

Unlike COM, the .NET Framework defines the Common Language Specification (CLS). As a result, no matter which language developers use, they have equal access to the framework. Developers building libraries are not forced to target each language explicitly. If they adhere to the set of features described in the CLS, their library will automatically be accessible to many languages. This approach ensures a consistent availability of features regardless of the programming language employed.



Programming in the .NET Environment
Programming in the .NET Environment
ISBN: 0201770180
EAN: 2147483647
Year: 2002
Pages: 146

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net