Why Learn Yet Another Language?

It seems that all too often someone comes up with a new and improved tool to solve the crisis of the day, when in fact it's the same crisis everyone has been dealing with for years and a plethora of existing tools to choose from already exists. The current crisis of the day is developing a software application that is network aware, database connected, web serviceenabled, and any other advanced feature that clients , customers, and management alike need for the next generation of software applications.

So, why create a new language? After all, there are so many languages out there to choose from; surely one of them would suffice to do the job. We have Visual Basic for high-level abstraction and C++ for expressiveness and raw power. Although these languages are great and fill a vital role, the real need for a new language is not so much the language itself, but the idea behind a new platform for software development in general.

In the same way that some people like the city life but others prefer the quiet countryside, the choice of languages is also a personal preference. Of course, language wars are often debates over language semantics, the expressive power and performance versus ease of use and high-level constructs such as object-oriented features. However, one thing has always remained constant: the need to reach the Holy Grail of software engineering, code reuse. Or, better yet, component-based development. The ability to create a component and use it in a software application that is written in another programming language is what developers have been searching for. Many attempts and standards have been created to address this very issue. This includes CORBA, COM, DCOM, Win32 libraries, and so on. However, each solution has had a single unavoidable roadblock: a common type system that unifies all languages and allows them to pass information back and forth in a consistent well-defined format.

Learning Common Types

Take an integer for example. Simple things such as the size of an integer are often taken for granted. Integers might not necessarily be the same size (or even in the same byte-order) on two different machines and operating systems. If you said 32 bits, you'd be somewhat correct. An integer on a 32-bit processor is in fact 32 bits in size. However, some languages such as C++ do not specify the size of an integer. They merely state that an integer is the size that can be handled by a single processing cycle for the target CPU. Okay. That's good for cross-platform languages such as C and C++. However, it makes it difficult for interoperability with other languages, such as Visual Basic.

The common type system does more than just define the size of an integer. The common type system provides three major functions:

Provides a framework for cross-language integration, type safety, and high-performance code.
Provides an object-oriented model that supports the complete implementation of many programming languages.
Defines rules that languages must follow. This ensures that objects written in different languages can interact with each other.

The common type system has two classifications of types: value types and reference types.

Understanding Value Types

Value types contain their data directly. In addition, value types are allocated on the runtime stack; this will become important during the discussion of the garbage collection system. Value types can be built-in, such as a char or int type, or user -defined via the struct keyword. Table 2.1 provides a listing of the value types in the Framework Class Library, hereafter referred to as the FCL.

Table 2.1. Value Types Defined by the .NET FCL

Category	Class Name	Description	C# Data Type
Integer	`Byte`	An 8-bit unsigned integer	`byte`
	`SByte`	An 8-bit signed integer*	`Sbyte`
	`Int16`	A 16-bit signed integer	`short`
	`Int32`	A 32-bit signed integer	`int`
	`Int64`	A 64-bit signed integer	`long`
	`UInt16`	A 16-bit unsigned integer*	`ushort`
	`UInt32`	A 32-bit unsigned integer*	`uint`
	`UInt64`	A 64-bit unsigned integer*	`ulong`
Floating point	`Single`	A single-precision (32-bit) floating-point number	`float`
	`Double`	A double-precision (64-bit) floating-point number	`double`
Logical	`Boolean`	True or false Boolean value	`bool`
Other	`Char`	A Unicode (16-bit) character	`char`
	`Decimal`	A 96-bit decimal value	`decimal`
	`IntPtr`	A signed integer whose size depends on the target platform	`IntPtr`
	`UIntPtr`	An unsigned integer whose size depends on the target platform	`UIntPtr`

NOTE

Value types with an asterisk in the description are not compliant with the common language specification (CLS). That means those particular types are not required or supported by all .NET- targeted languages. All Microsoft languages, such as VB .NET, C#, Managed C++, and JScript support the types listed in Table 2.1.

Table source: msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconthenetframeworkclasslibrary.asp

Value types created within the scope of a method exist only for the duration of that method. After the method has returned, its call stack is reclaimed and the value type no longer exists. Classes can also contain value types. In this case, the data for the value type exists for the duration of the existence of the object.

Understanding Reference Types

Reference types are objects that are allocated and managed by the garbage collector. Reference types are instances of classes created using the new keyword. An example would be the following:

MyClass myClass = new MyClass( );

The myClass instance is created on the heap and managed by the garbage collector. Reference types do not disappear when they go out of scope the way that value types do. Rather, as the name implies, when all references to a reference type are gone, the garbage collector will reclaim the memory. More about the garbage collector will be discussed later.

Reference Versus Value Types

The key difference between value type and reference type is the way they are passed to methods . Depending on what language you're coming from, this might take some getting used to. For instance, in Visual Basic, not VB .NET, parameters default to pass by reference. That means that if a method (sub/procedure) modifies the parameter, the caller will see that modification. This is not the case with value types. Value types are passed to a method via a copy. A copy of the value is created on the call stack to the method. Sometimes it's just easier to see it in code, as in Listing 2.1.

Listing 2.1. Passing a Value Type to a Method

class MyClass {
    static public void ByValue( int i) {
        i = 20;
    }
}

int i = 10;
Console.WriteLine( "Value of i := {0}", i );
MyClass.ByValue( i );
Console.WriteLine( "Value of i := {0}", i );

In Listing 2.1, a local variable i is declared and set to an initial value of 10. The WriteLine method displays the value to the output window. Next , the code passes the local variable i to the ByValue method of MyClass . In reality, a copy of i is placed on the call stack and not the actual variable i . This point is crucial. The code within the ByValue method is free to change the value of the parameter that was passed in; however, after the method has returned, any modifications made by the method to the parameter are lost. Therefore, the last WriteLine method will display the following message: Value of i := 10 .