So far we've been keeping a big list of module string names, which we then resolve to actual module symbols during compilation and introspect for IRCPlugin subclasses to instantiate. This had the drawback that you had to go modify the file (plugins/package.d) whenever you add or remove a plugin.
With this new approach each plugin module simply has to mix in a ModuleRegistration template, and module constructors are used during runtime to register that module for plugin instantiation. The introspection to find the IRCPlugin subclass is naturally still done during compilation, at point of mixin.
Some steps were necessary and new modules created to take to avoid cyclic dependencies. Lastly, this project no longer builds with 2.084 compilers, and the new lowest supported is 2.085.
So far we've been keeping a big list of module string names, which we then resolve to actual module symbols during compilation and introspect for
IRCPluginsubclasses to instantiate. This had the drawback that you had to go modify the file (plugins/package.d) whenever you add or remove a plugin.With this new approach each plugin module simply has to mix in a
ModuleRegistrationtemplate, and module constructors are used during runtime to register that module for plugin instantiation. The introspection to find theIRCPluginsubclass is naturally still done during compilation, at point of mixin.Some steps were necessary and new modules created to take to avoid cyclic dependencies. Lastly, this project no longer builds with 2.084 compilers, and the new lowest supported is 2.085.