std.reflection prototype

Jacob Carlborg via Digitalmars-d digitalmars-d at puremagic.com
Wed Apr 1 23:57:26 PDT 2015


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/mfcgj3$12a0$1@digitalmars.com
[2] http://forum.dlang.org/thread/mfci6o$13oa$1@digitalmars.com
[3] http://forum.dlang.org/thread/ks1brj$1l6c$1@digitalmars.com
[4] http://forum.dlang.org/thread/kok86c$126l$1@digitalmars.com

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list