Kapps via Digitalmars-d
digitalmars-d at puremagic.com
Sun Mar 29 22:26:10 PDT 2015
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
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?
More information about the Digitalmars-d