grauzone wrote:
I had the same problem when writing the D/Objective-C bridge.
Basically, if you ask the Objective-C runtime to instanciate a class
not previously registered, it won't find it. My choice was to require
manual pre-registrations of the classes you want to use, and register
everything that is possible lazily as soon as you use a bridged class.
Yes, and that "pre-registration" is only there to make the compiler
generate the required compile-time reflection code (like with .tupleof
or __traits). While compile-time reflection is probably really more
flexible than runtime reflection, requiring this kind of "registration"
remains a weakness of the compile-time approach.
Solutions would be to make reflection fully dynamic (as you said) and
extend RTTI for that, or to provide better ways to inspect modules as a
whole.
For the latter, maybe __traits should just be able to inspect all
members of a module, and to follow imports. Or one could introduce some
kind of "module preprocessor", which enables you to execute code for
each module at compile time (transparent for the processed module).
Just by the way, annotations would also be nice. It's annoying to add
additional information to members without them. This "additional
information" can be stuff like default values, versioning of
serializable members, behavior for missing values on deserialization,
human readable help text if you want to use reflection to read/write
user configuration files...
I've seen four good uses of annotations in the past that could not
easily be replaced:
- dependency injection configuration
- ORM configuration
- event broker registration (this method should be called on this event)
- test method/class registration
This brings up an issue. Let's say I use static constructors to
configure a serialization library, then use a static constructor to read
objects using this serialization library. There's no way to define an
order in which static constructors should be run within a module, but
here it makes a huge difference. It would be very convenient to have as
much of this configuration as possible in a readable format and not
static constructors.
