Like C# and Java, Delphi makes rich runtime type information available to developers, facilitating the use of reflection. Reflection is just another paradigm, but incredibly useful for performing certain tasks.
For example, one of the tasks I use reflection for is to discover classes decorated with a SystemInitializer attribute on application startup.
Instead of putting all the configuration information into a single class, I’ll use several, each responsible for a specific initialization need. The classes are stored in a common initialization folder.
A SystemInitializer class is executed to bootstrap the application. It identifies initialization classes, sorts them by priority, then executes them in order. This makes it very simple to add or maintain initialization code. My motivation for this approach came from Ruby of Rails.
Another task I often use reflection for is to identify command classes and register them with a command registry. This is a nice way to decouple commands from the registration process. Adding a command to the registry is as simple as declaring it.
This magic relies upon two features: Attributes and the RTTI classes. To declare an attribute in Delphi, inherit from TCustomAttribute:
This attribute has two properties, Text and Hint. It can now be used to decorate a class:
In the above example, the properties of the command attribute instance for the TRosterCommand class will be initialized with the text ‘roster‘ and the hint ‘gets roster information for the current user.‘
Auto-registering our Commands
To discover the classes decorated with the TCommandAttribute at runtime, we now use the RTTI. This is done once on start up, so the performance costs are small. Although reflection is a lot slower than directly coding the same operations, there’s not really a noticable delay in most cases, especially on smaller code bases. Delphi’s RTTI is pretty quick.
In the above code, I am searching for matching types in the current application and registering them with internal data structures. It’s that simple…or so I thought.
For some reason, some commands were not being identified via RTTI. According to the official documentation I was doing everything correctly:
“To obtain a list of all the types declared in an application, use the TRttiContext.GetTypes method. It enumerates all publicly visible types (the ones declared in the interface section of units) and returns an array of TRttiType objects.”
But my debugging code verified certain commands were not being discovered…
After a bit of head scratching, I realized the Linker must have determined that the class isn’t used, as I am not directly referencing it anywhere, so it gets unceremoniously dropped. This doesn’t happen in C# or Java, which is what threw me off guard in this case. I just assumed the presence of the attribute would be a hint to the compiler.
My thoughts turned to perhaps the existence of a compiler directive I could use to tell the compiler not to drop a type during the linking process. It turns out there is such a directive:
However, you have to include it in the project .dpr file, and it is global in effect. Effectively, the Linker drops nothing, which unfortunately causes code bloat. So this is not a solution. The idea of so much bloat makes my eyes twitch.
The next consideration was to abandon this usage of reflection completely, and use the traditional approach to registering classes with a container or registry in the initialization section of the unit containing the command class. This is actually quite neat, you see it in frameworks like DUnitX.
But what’s the point in having Attributes and RTTI if you can’t use them? There must be a way.
Another Way, Combining the Two Approaches
In the base class TCommand add a public method that does nothing:
In each command unit, for example uRosterCommand, add:
Now the type is included by the linker, hence detected by RTTI, and it is decoupled from the registry and the registration process. Success!
In fact, it’s probably worth creating a global utility method that can be used anywhere for this kind of purpose, perhaps named RegisterWithLinker or something similar.
Lazy Command Creation
Finally, we create a command on demand. A command may contain state, so it is never shared, a new instance is always created. If required, we could add a property to the attribute and a little logic in our command registry to override this behavior. But that’s not needed in this case:
In this post I’m not advocating the usage of reflection over any other technique. Indeed, as Delphi is a RAD environment, in a GUI application I may not use this approach, it depends on context.
Delphi has several good initialization mechanisms built-in already, including an Initialization Section in each unit, and Class Constructors for each type. Reflection is just another tool in the toolbox. When reflection may be useful, Delphi’s reflection system is a very capable mechanism.
I essentially learn on the go, so this post is a future reference for me. I hope it may be helpful to someone else. For more information on Delphi’s RTTI, see here.
Chapter 16 in Marco Cantu’s Object Pascal Handbook is dedicated to reflection and attributes, and there are videos available on Embarcadero Academy, and YouTube.
Daniele Spinetti and Daniele Teti have an interesting example of using attributes for validation of business objects in their Delphi Cookbook.
Chapter 12 of Chris Rolliston’s classic Delphi XE2 Foundations is dedicated to RTTI.
Here is a snippet from the chapter Mind Your Language in Pawel Glowacki’s excellent book, Expert Delphi. Here he demonstrates identifying attributes on methods as well as types:
Back to my application, for full context, here’s the main loop which uses the Command Registry:
The Parser uses the Command Registry to identify and create commands, if the user enters an invalid command, a non-registered special purposed TInvalidCommand is returned by the parser, which on execution simply displays “Invalid Command, type help for more information”
Lastly, the structure of the project containing the decoupled commands added to date: