C# is a language that is diversifying in terms of what it regards as a proper and fit programming paradigm. 

When it reached version 3.5, C# had started to accumulate facilities that took it in the direction of functional programming - lambda expressions, yield, anonymous methods and so on. In the latest version, 4.0, it seems to be adopting the dynamic language model with the consequential devaluing of strict typing. Is C# becoming something of a mess by adopting models that go against its birthright of strict typing and object-oriented procedural code? 

We take a close look at some of the new features introduced with version 4.0 and try to work out what sort of language results if you mix dynamic with strict typing.

On being dynamic in C#

Strong typing isn't necessarily the good idea it first seems to be - it has some advantages but so does dynamic typing. It is also true that it is the biggest current divide between programmers and programming languages is into camps that swear allegiance to the strong typing principle or simply attempt to ignore type altogether.

C# started out as a young, clean, strongly-typed language but as it reaches its middle age it is displaying signs of being envious of the currently popular dynamic languages. This is made worse by the desire to meet the demand to be simpler, easier to use and more productive.

The evidence of this envy is the simple fact that C# 3.0 introduced many new features that arguably weakened compile time type enforcement while still trying to play within the rules.

Some definitions

First it is worth saying what strict, static and dynamic typing are all about.

A language uses strict typing if it demands that every item of data has a type and can only be stored in a variable of that type. Usually things are a little more complicated in that types form a hierarchy and a variable of a given type can store data of that type and types derived from it. Put simply a strictly typed language "worries" about type and generates type exceptions when it thinks you are trying to store data of the wrong type in a variable. 

Contrast this with a freely typed language that tries to make it possible for you to store any data in any variable and tries to make sense of what you want to do taking the actual type into account. Put simply a freely typed language tries to ignore data type as much as possible and generates a type exception only when you write something that cannot be reasonably achieved. the type free language motto is "if it can be made to work its ok".

A strongly typed language can also be statically or dynamically typed.

Static typing means that all data types can be worked out at compile time and any errors can be flagged at compile time. In other words you can tell all types simply by reading the code.

A dynamic language allows a variable to determine its type at run time. In this case you can't necessarily work out the type of a variable by simply reading the code and not all type errors can be picked up at compile time.

Notice that there are two variations possible on dynamic typing. You could enforce a rule which fixes the type of a variable once it is known i.e. variables can't change their type once set. Or you could implement fully dynamic typed variables that can be used to store anything anytime and change there type according to what is stored in them.

You might at this point think that its all very simple but in an object oriented language like C# type actually plays a role in determining what happens in a program - it can change the flow of control and hence things are more subtle.

Static typing

Before moving on to consider dynamic typing it is worth spending a few minutes considering how static typing works and how it determines the way things work in C#.

First, recall that in C# 2.0 you always had to determine the type of the result of an expression and use an appropriate type or super type to store it and this determination had to be made at compile time.That is C# 2.0 is a statically typed language.

Even now  the compiler always looks at an expression, determines the type of the expression and makes sure that this is compatible the "assignment" variable.

Notice that this applies to assignment proper, method parameters and return types. Type determination can also affect the flow of control in a program - but static typing can only determine it at compile time.

For example, consider the two overloaded methods:

 public string MyMethod(int i)
 { return "Integer"; }
 public string MyMethod(double f)
 { return "Double"; }

then when you write:

MyObject.MyMethod(X);

which method is called depends on the type of X.

If X is an int the first method is called and if it is a double the second method is called.

You may well be used to the idea that overloaded methods are called according to signature but you might not have realised how important this makes the determination of type as part of the flow of control in your program.

The method call MyMethod(X) resolved according to the signature of the call might be thought to be expressed by the equivalent code:

MyClass MyObject = new MyClass();
int X = 1;
if (X is int)
{
 MyObject.MyMethod1((int)X);
}
else if (X is double)
{
 MyObject.MyMethod2((double)X);
}

but notice that this determines the type of X at runtime not compile time.

If you examine  the code you can see that MyMethod1 is always called - there is no possibility of anything else happening because X is always an int. In this sense the whole if statement and testing is completely unnecessary you might as well write:

int X = 1;
MyObject.MyMethod1((int)X);

In a statically typed language there is no way a variable can change the type it is assigned when it is declared.

However even static typing is a little more subtle than this. The extra complexity comes from the idea that any type that derives from another type should be usable in place of the parent type.That is, if I declare a class as:

public class MyClass2:MyClass
{
 '''
}

then MyClass2 can be used in place of MyClass and generally treated as if it was of type MyClass.  For example a method like:

public string MyMethod(MyClass o)
 { return "MyClass"; }

can be called with a parameter of type MyClass or MyClass2. So, from the point of view of method signatures, derived classes act like their parent classes. So what if we now overload MyMethod with a specific version for MyClass2?

public string MyMethod(MyClass2 o)
 { return "MyClass2"; }

Now if I call MyMethod with a parameter of type MyClass2 which method will be called?

The answer is, unsuprisingly the one with the signature that matches the parameter most closely. In this case the version of MyMethod with the MyClass2 parameter is called.

This is a general principle: the method with the signature that most closely matches the types used in the signature is used. 

<ASIN:1430225491>

<ASIN:0321718933>

<ASIN:0470467274>

<ASIN:0470563486>

<ASIN:1430225254>