On Thursday, 2 April 2015 at 06:57:25 UTC, Jacob Carlborg wrote:
On 2015-04-02 02:28, bitwise wrote:
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.
As I said, the reason for implementing RTInfo for modules was
to _not_ have to register anything.
There are other good use cases for both RTInfo and RMInfo
(runtime module info), they are a more generic solution. Two
other threads about unit testing [1], [2] is a good use case.
RMInfo can be used to collect all unit test functions and
create a custom runner.
Here's [3] one example where a unit test runner makes it
possible to have CTFE unit tests. This proof of concept only
scans the current module, here RMInfo would be really handy to
scan all modules.
Here's [4] one example where RTInfo is used to check virtual
methods. All virtual methods are required to be marked with
@virtual.
There's a lot of missing info in ModuleInfo and TypeInfo. For
example MemberInfo_function contains no information about
parameters, return types, attributes and so on.
[1] http://forum.dlang.org/thread/[email protected]
[2] http://forum.dlang.org/thread/[email protected]
[3] http://forum.dlang.org/thread/[email protected]
[4] http://forum.dlang.org/thread/[email protected]
Ok, I think I understand what you're suggesting now, which is
that you want a library to be able to override RTInfo in order to
add it's own metadata to all types, which raises the question,
what if more than one library wants to add metadata? And I think
this question was addressed by the suggestion of the AA for
RTInfo where the module's fully qualified name was the key, which
won't work because of separate compilation... right?
So in my case I could just update my RTInfo to generate a
reflection for each type, and make it accessible using a UFC or
something.
If I understand correctly though, the idea has been dismissed as
being impossible due to separate compilation, right? Is there any
leads on this at this point?
