Dynamic typing

In dynamic typing, or late binding, the type of an object or expression is not known until run-time. The variable is "untyped" and this is notated differently among languages. In C# and VB.net the variable is of type Object,  in classic VB of type Variant and in Perl there is no type information prepended to the variable.

In dynamic typing the variable can hold a value of any type and subsequently the value and its type can change during runtime. It is not a type-safe affair since type checking cannot be done at compile time and the object must be interrogated at runtime for its members. Because of this some run-time errors cannot be avoided and it also costs in terms of performance. Another disadvantage is that you do not have access to some IDE features such as Intellisense support since there is no type library to import (borrowing the term from the COM+ world).

Example 2

class Class1
 {
 public int MyMethod(int x)
 {
 return x;
 }
 }



object myobj;
 myobj = new Class1();
 int myint = myobj.MyMethod(10);

This example both in VB.net and C# would resolve to a compile time error since there is no such method MyMethod belonging to type Object, since static typing checks the compile time type (Object) and not the runtime type (Class1). Thus VB.net and C# display their static language properties.

The same concept holds true even if the method does not exist at all :

Example 2a:

class Class1
 {
 public int MyMethod(int x)
 {
 return x;
 }
 }
object myobj;
myobj = new Class1();
 string mystring =
myobj.MyMethodWhichDoesNotExist(
"this is a string");

Again, this example both in VB.net and C# would resolve to a compile time error since there is no such method MyMethodWhichDoesNotExist belonging to either type Object or Class.

However, by using the 'option strict off' compiler directive, VB.NET acts as a dynamically typed language and type checking is deferred until runtime; subsequently it will not complain at compile time that it cannot resolve the binding to a method called MyMethodWhichDoesNotExist. Now the operation is directed by the runtime data and the object's type is asked for the method by using the method name as a string. If it does exist then the method call gets bound, if not a runtime exception is thrown.

Not real late-binding

Of course since you have Class1 type information ahead at compile time the above example has no particular use; however it demonstrates the late binding concept. Also, since you know the type at compile time you could just employ casting from type Object to the according type:

 object myobj;

myobj = new Class1();
 myobj1 = (Class1)myobj;
 myobj1.MyMethodWhichDoesNotExist(
"this is a string");
//compile time-error

So really no late-binding magic is taking place here.

For true late -binding think of the COM+ example CreateObject with no type library where the compiler has no knowledge of the type at compile time and thus no chance the compiler knowing the members of the class ahead, since the type is constructed at runtime:

Dim myobj As Object
 Set myobj = CreateObject(
"Excel.Application")

The same example with early binding , where you have type library information (compile time information on the type) and thus can declare the type of the variable, would be :

 Dim myobj As Excel.Application
 Set myobj = New Excel.Application

Polymorphism

The term late binding is used in static languages as a synonym for polymorphism. A method denoted with the 'virtual' keyword cannot be bound to the variable at compile time; it can only be determined by the actual object type at runtime. This means that when calling a 'virtual' method by using a variable of the base type that points to an instance of the derived type, the method to be called must be determined at runtime. However the base class MUST support the method and this is enforced at compile time.

Example 3

 class Class1
    {
        public virtual int Method1()
        {
            return 1;
        }
    }

   class Class2 : Class1
   {
        public override int Method1()
        {
            return 2;
        }

   }

         class Program
   {
      static void Main(string[] args)
      {
         Class1 objA = new Class2();

         int x = objA.Method1();
         Console.Write(x.ToString());
         //prints : 2
      }

   }

In this example, the compile time type of objA is consulted and Method1 is looked up which does exist for Class1. Since the method is denoted as 'virtual' the next step is to consult the runtime type (which is Class2) and follow that type's method entry in its Metadata table. The method address is retrieved and bound to the variable. Again, as stated above this is not real late binding since the method must be known at compile time.

<ASIN:0735621632>

<ASIN:B0028AD7PA@ALL>

<ASIN:073562609X>