On Monday, 30 March 2015 at 05:06:14 UTC, bitwise wrote:
This definitely should be a library solution.
In terms of what Andre was suggesting, I think my
implementation is 90% of the way there, so if the will was
there to add something like std.reflection to phobos, it
wouldn't be much of a leap.
But it seems silly, to not use code in druntime.
I kind of agree. If I had things my way, all reflection info
for all classes would be compiler generated so that it was
guaranteed to be there for tools, interop and such. If people
were really worried about code bloat, the reflection info could
simply be turned off with a -no-reflection flag or something.
In terms of playing around with the compiler and the type
system, I'm not sure how helpful I could be right now. I'm
pretty sure comprehension will not be a problem, but I've got
quite a bit of reading to do before I'm up to speed with whats
going on with dmd and the type system.
When I tried mine
(https://shardsoft.com/stash/projects/SHARD/repos/shardtools/browse/source/ShardTools/Reflection.d),
which was admittedly a while back, the template bloat was
actually a significant problem. On Linux and OSX, the build for
just the unittest library would generate an over 40MB executable.
On Windows with Optlink though, it was only 4MB, so perhaps there
are optimizations that could be made to reduce the size on OSX /
Linux. Either way though, that's way too much bloat for something
in druntime, and I don't think it's necessary. While it might be
nice to use RTInfo to generate reflection data for your whole
program, most people would be perfectly okay with at most a few
modules, possibly recursively. Also, from what I can tell you
generate a class for every symbol. This could generate a
significant amount of bloat as well because it would generate
further TypeInfo for each of these classes. I could be wrong
here, but if that's the case, perhaps changing to structs would
be a better choice if possible?
