std.reflection prototype

[bitwise via Digitalmars-d]

> 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.