Dynamic binding

(object oriented programming:)
Also known as late binding, and the opposite of static binding (or early binding).

Suppose you have an object *x, and you call a method x->meth(args...) (I'll be using C++-style pointers to objects for the examples, as there the difference is most evident). Suppose further that x was defined X* x, for some polymorphic base class X. Then the compiler (usually) cannot know at compile time which method meth should be called!

Instead, it uses dynamic binding: The object *x contains sufficient information for the correct method x->meth() to be found. In C++, this typically takes place by storing in *x a pointer to its class' vtable, a table of function pointers to each of its methods. (Organising a vtable in the presence of multiple inheritence is decidedly non-trivial!) The compiler produces code which, at run time, accesses the function pointer for meth inside the vtable of *x and calls it. In particular, it cannot inline the call, since it cannot even know which function to inline!

Naturally, all this takes time, so dynamic binding is invariably slower than static binding. Assuming the vtable model, first the code has to follow a pointer from the object to the vtable (which is not too bad, but it's still another memory access), then it has to call code via a function pointer. And function calls through function pointers are slow compared to direct function calls (every such call guarantees a pipeline stall!). Still, if your problem needs dynamic binding, there'd be no way around having a function pointer -- you're in inherently slower territory.

Some programming languages employ dynamic binding exclusively: Smalltalk, Perl (see the discussion of @ISA), Python. Of course, any language with a compiler that can deduce types may sometimes be able to replace dynamic binding with static binding. For instance, in the following C++ code:

X* x = new Y;        // Y inherits from polymorphic base class X
x->colour(blue);     // (*)

the compiler could prove that the method call (*) must call Y::colour and bind the correct method (presumably either Y::colour or, if that doesn't exist, X::colour by inheritance) at compile time. But it's not required to do so.

In functional languages, this same term is used with a different meaning. It refers to how values of free variables are obtained in an expression; here, the values of free variables are obtained from the context in which the expression is evaluated. For example, with this ML-like code:

let x = 1
in
let f y = x + y
in
let g f y =
  let x = 3
  in
    f y
in
 g f 2

the value of the free variable 'x' appearing in 'f' would be 3 when it is evaluated by 'g', so in an ML dialect that used dynamic binding the value of this expression would be 5.

Of course, use of this strategy precludes referential transparency, as an expression might have a different meaning if it is evaluated in a context with different bindings for its free variables. For the most part it's older functional languages that use this strategy, as it is generally easier to implement than static binding. Examples of languages that use dynamic binding include older LISP dialects such as Emacs Lisp and LISP IV.