Reflection is, without a doubt, my favorite computer programming language feature. \u00a0It is unfortunate therefore that I’ve spent most of my professional life programming in C++, a language that has stubbornly refused to adopt a mechanism for class reflection. \u00a0There is a reason why I’ve stuck with C++ however; it is the highest level language available today that still provides unobstructed access to the hardware platform on which it sits. \u00a0Whatever its faults, it never\u00a0prevents me doing what I have to do.<\/p>\n
When Kyle Wilson<\/a> and I were laying out the design for Day 1’s Despair Engine<\/a>, low-level support for reflection was a must-have on the list of engine features. \u00a0We were designing the largest, most ambitious engine either of us had ever worked on, and we didn’t want it to be clogged with thousands of lines of boilerplate code. \u00a0We wanted a simple, easy to use mechanism by which common libraries for disk serialization, UI generation, network synchronization, script integration, and debugging could operate intelligently on a diverse field of heterogeneous objects. \u00a0We’d both been down the route of virtual “Save” and “Load” calls implemented on every object as well as the route of UIVehicle<\/em>\u00a0and NetVehicle<\/em>\u00a0proxy objects, and we were intent on finding a better way. \u00a0At the same time, however, we were keenly aware of the dangers of over-generalizing.<\/p>\n We knew that the engine we were designing would have to grow to support dozens of engineers and multiple simultaneous projects, and that it would have to be flexible enough to adapt to the unpredictable requirements of future games and hardware. \u00a0Taking all this into consideration, here is the list of goals we drafted for our reflection system:<\/p>\n In addition to these general requirements for the system, we had several specific uses for reflection already in mind which added their own requirements:<\/p>\n It fell on my shoulders to provide the initial design and implementation of Despair’s reflection library, dsReflection. \u00a0Luckily reflection is nothing new to games, so I had a lot of inspiration to draw upon. \u00a0One of my favorite early implementations of reflection in a game engine is in the Nebula Device<\/a>. \u00a0The Nebula Device’s approach to reflection was fairly straightforward–hard coded companion functions for every object populated tables with metadata like command names and function pointers–but it was used to great effect to expose a great deal of the engine to Tcl and from there to perform serialization and network synchronization.<\/p>\n Although the Nebula Device was a great proof-of-concept for me, it didn’t meet many of the requirements Kyle and I had put forth. \u00a0It was very limited in the kind of data it could reflect and syntactically it was messy and required a lot of boilerplate code. \u00a0The inspiration for the syntax of Despair’s reflection definitions came instead from C# and luabind<\/a>. \u00a0We hoped to be writing a lot of tool and support code for the engine in C# so it made sense to try to match its syntax, and luabind is an ingenious example of how C++ compilers can be manipulated into parsing very unC++like code.<\/p>\n What I ended up with is an embedded, domain-specific language implemented through a combination of clever operator overloading and template metaprogramming. \u00a0Many of the core concepts in dsReflection are enabled by features of Boost’s metaprogramming tools<\/a>. \u00a0The reflection definition language is used to construct metadata for classes. \u00a0The metadata holds references to fields and methods of a class. \u00a0Fields can be raw member pointers as well as combinations of getters and setters. \u00a0Methods can be member functions with variable numbers of parameters of mixed types. \u00a0Methods can expose concrete, virtual, and even pure virtual functions. \u00a0All reflected elements can be tagged with user-defined properties similar to Attributes<\/em>\u00a0in C#. \u00a0These properties are how external systems annotate classes, fields, and methods with information specific to their needs. \u00a0Reflection definitions can be applied to non-polymorphic classes, but to take advantage of the full feature set reflected classes must derive from Reflection::Object<\/em> which introduces a single virtual function. \u00a0In its initial implementation dsReflection supported global and file static variables and functions through reflection namespace definitions. \u00a0This capability still exists, but we’ve found little use for it and I’ve often considered removing it entirely.<\/p>\n\n
\n