Search Eridotnet


Monday, June 9, 2008

Quick Overview of Type system concepts in .NET 2.0 (and also in .NET 3.0 and 3.5)

Hello all!

First, I admit that I have very long silence after my last January 2008 entry. I've been busy doing my software development projects and balancing between my family leave.

Before I continue about the next series on LINQ, I want to clarify type system in .NET 2.0, 3.0 and 3.5.

There are these jargon/buzzword or programming language term in .NET and others:

  • Statically typed
  • Strongly typed
  • Implicitly typed
  • Dynamically typed

First of all, type system in CLR 2.0, the CLR that's first been brought by .NET 2.0, and has been available since .NET 1.0, is statically typed.

Statically typed means once you define a type of a field or a variable, it can't be changed afterwards. This is heavily related to a strongly typed concept.

An easy example is how the variables, properties, fields in .NET are declared. It's always mention the type declaration first, and then the Type will be "forever" glued to the object it declared.

Simply put, if you have variable:

TableLayoutPanel tablePane = new TableLayoutPanel();

The tablepane has typed TableLayoutPanel, and the type can't be changed later in runtime. Only then can be upcasted to a higher level object (derived object).

Strongly typed means statically typed variable that has more specific type assigned to it, instead of just Object type. The use of Object type is often not recommended, since it can mean any types.

Strongly typed has many uses and can be easily understood in using collections. Generic collections are very good samples of strongly typed concept.

For example, instead of defining this:

        ArrayList arrayint = new ArrayList();

It's more strongly typed to use this:

        List<int> listint = new List<int>();

Why? ArrayList contains a list of objects. This means a bad practice, since you can just add any kind of types into an ArrayList. List<T> (generic List) is better, since the member of List is a typed T, just like the example above.

Strongly typed are also more efficient in performance, since it requires less casting.

Now, what is implicitly typed? Sadly enough, there are less conversation about this concept. But deep inside CLR 2.0, there is one good sample, array. An array, as documented in MSDN, is derived from IEnumerable, IList, ICloneable, and ICollection.

public abstract class Array :
IList, ICollection, IEnumerable

But in reality, as also mentioned in MSDN Library:

"In the .NET Framework version 2.0, the Array class implements the System.Collections.Generic.IList<T>, System.Collections.Generic.ICollection<T>, and System.Collections.Generic.IEnumerable<T> generic interfaces. The implementations are provided to arrays at run time, and therefore are not visible to the documentation build tools. As a result, the generic interfaces do not appear in the declaration syntax for the Array class, and there are no reference topics for interface members that are accessible only by casting an array to the generic interface type (explicit interface implementations). The key thing to be aware of when you cast an array to one of these interfaces is that members which add, insert, or remove elements throw NotSupportedException. "

See? This is, by any means, is implicitly typed. Therefore, if you have:

  • String[] is simply an implicit type of Array<String>

  • Int32[] is simply an implicit type of Array<Int32>

What about dynamically typed? Dynamically typed is easy, it's simply an object that can have any type, or an object where its type can be changed dynamically at runtime. You can spot this in a JScript or JavaScript language. It's also heavily used in Python, Ruby, and others.

Now, I'll bring you more heavy use, samples, and best practices of these conceptual terms in my next installments of quick thoughts series. :)