Preface

In software development, metaprogramming is one of those words that sounds fancy and sophisticated—and somewhat intimidating at the same time. But what does it mean to be doing metaprogramming? The meta prefix can mean changed or higher. It can also mean after or beside, depending on the context. All of those terms describe the various forms of metaprogramming that we cover in this book.

You may choose to do metaprogramming in order to change code to support a higher level of abstraction within your system or to inject some new behavior that suits your particular needs. You may choose to do these things at compile time, between compile time and deployment, or even at runtime. Because of the flexible nature of the meta prefix, all of these scenarios qualify as metaprogramming.

No matter your reasons for doing metaprogramming, you must have a firm grip on the larger architectural picture of your project to do it effectively. That’s why metaprogramming is sometimes considered a dark art, to be practiced only by senior developers and architects. Nothing could be further from the truth. Everyone can do some form of metaprogramming. By manipulating code with other code the metaprogramming way, you can suddenly tackle classes of coding problems that you were never able to overcome before.