Currently in object.d in druntime there's
a template, RTInfo, declared something
like this:
[snip]
Thanks for the breakdown! Those pull requests make a lot more
sense when read in the proper context ;)
The main reason for implementing RTInfo
for modules is to implement reflection.
With the template instantiated for each
module you could scan the module for class and methods and
build up reflection
data completely transparently without
the user needing to register any types
or similar.
If I'm understanding correctly, doing it this way is to avoid
making changes to the compiler, right?
I don't understand this decision because it seems that most of
the needed infrastructure is already built into ModuleInfo, and
that it just needs to be completed. It would eliminate the
problem of template/code bloat from a library like mine, and at
the same time, would not require the user to register any types.
The downside would be susceptibility to things like .NET
Reflector, making binaries very easy to crack/decompile, and of
course, the extra space it took for the metadata. But, the
generation of the metadata could be made optional via command
line switch. Metadata could either be disabled completely, or
partially with something like --no-verbose-rtti, which could omit
all the human readable portions of the metadata, while leaving
behind whatever was needed for precise GC or whatever else may
need it. Of course, the inverse would also be an option, to omit
all type info and enable it manually via --verbose-rtti.
Failing all of the above, I suppose my reflection library does
the job well enough for my needs. Some work could be done to
optimize the binary size, but feature-wise, I find it more than
complete enough. However, I am thinking about making it more
versatile in terms of what is generated, because that seems to be
a common request.
Something like this might make sense:
module test;
class Test1{}
@Reflected class Test2{}
@NotReflected class Test3{}
///////////////////
module reflection;
enum ReflectionMode {
Inclusive, // include all classes unless specified
Exclusive // exclude all classes unless specified
}
template moduleReflection(alias mod, ReflectionMode m) { ... }
///////////////////
module test;
mixin(moduleReflection!(test, ReflectionMode.Inclusive));
///////////////////
ReflectionMode.Inclusive would generate reflection for Test1 and
Test2,
ReflectionMode.Exclusive would generate reflection for only Test2.
I'm not sure it's possible to make recursiveness of reflection
optional without losing compile-time availability of major
features though.
This is needed for sure. For example do you
count how many subjects on .learn are about
__traits(allMembers,... or __traits(getMember,...
Yeah, I agree these are confusing... along with type-tuples, and
CTFE. I think all three of these are hard to grasp without
knowledge of how a compiler works.
About the design i would rather see this as
a user choice, eg the reflexion as a mixin
template that you can mix in a class or a struct you want to be
filled with info.
This remark is related to the size problem
pointed in the previous posts.
I would like to make things as flexible/optional as possible
without being intrusive to user types. UDAs are about as far as
I'm willing to go with per-type boilerplate.
