Chapter 14: Dynamic Programming

We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.
— Paul Graham, Hackers and Painters

Overview

Most of the topics we've covered in previous chapters took a look at the CLR and its type system from the standpoint of code written in a high-level language (e.g., C#, VB, C++/CLI) and compiled to IL. Such code interacts statically with the CLR, meaning that compilers decide during compilation (using early binding) what types your program will work with and what code will get executed. Conversely, dynamic code defers such decisions to runtime (using techniques like late binding), enabling programs to use information only available at runtime to make key decisions like which types to use and which code to execute. This can even include some degree of dynamic code generation.

Some constructs built right into the CLR's type system fall in between the two categories. For example, virtual methods delay until runtime the decision of precisely which code to execute by using an object identity-based virtual table lookup. Even JIT compilation can be considered a form of dynamism because the actual native code that gets executed isn't generated until runtime (except in the case of NGen). But in addition to those, there is a set of libraries available that enables you to take it a step further by manipulating metadata, instantiating types dynamically, executing bits of IL, and even generating new metadata to be saved to disk or executed. This interaction occurs through runtime API interactions with CLR data structures, and not by statically emitted IL. This is called reflection.

Reflection provides a means by which to extend your programs in a fully dynamic way. This capability is useful for writing metadata-driven harnesses, creating object model inspection or reporting utilities, generating or executing code using some program input (e.g., compilers or configuration-based type generation), creating applications that make runtime decisions about what code to load and run — for example hosting add-ins or plug-ins — among many other uses. The reflection system generally consists of two pillars, each isolated into its own namespace: System.Reflection and System.Reflection.Emit:

• System.Reflection enables you to inspect metadata, while System.Reflection.Emit enables you to generate it. An extended feature of the reflection library, delegates, permits you to form typed function pointers over code and then pass instances around in a first-class way. It has direct support built into the runtime and offers both static fast path and fully dynamic capabilities.

• System.Reflection.Emit provides abstractions that actually generate metadata and code at runtime. You can generate new types, type members, IL, new assemblies, and so forth. This information can then be instantiated for use immediately or saved to disk as a DLL or EXE for later use. The library can also emit debug symbols so that any code that you generate gets the ability to step through execution in a debugger for free. A new feature in version 2.0 called Lightweight Code Generation (LCG) allows for dynamic and quick creation of new functions for immediate execution.

As with anything, we'll take a look at how to use these constructs, but more importantly at how to select the right tool for the job. Dynamic programming can be several orders of magnitude slower than static programming because you delay until runtime many decisions that would have otherwise been made at compile time. Hence, using them incorrectly can have a notable impact on your application performance. Dynamic programming is extremely powerful, on the other hand, and is made possible because of the CLR's fully self-descriptive metadata system. When used correctly, it can enable you to write code that you never even thought was possible.