Permalink
Reply
Practical example: some framework allows it's user to define types of some messages. It can be done by manual calls like something.registerMessage!T1(), something.registerMessage!T2(). Other way is to leave it to framework: just annotate T1, T2 with @Command UDA and call some core framework mixin once to generate all the boilerplate.
And here come troubles. getSymbolsByUDA is not recursive and works for single module only. At the same time it seems there is no way to list all imported modules to get symbols from them. So we are back to boilerplate - just listing manually all modules this time instead of all types.
I've seen this thread during my search: https://forum.dlang.org/thread/uladyipxlerudtmsljky@forum.dlang.org
>__traits(allMembers, package) will list names of imported packages but not which modules.
In my tests it resulted in something like "object", "framework" for __traits(allMembers, framework) (I'm omitting all actual types in it as we talk about modules only). Why is it done this way? How is it useful?
How to list unknown sub-modules? (and not walking the source tree dir). Is there a compile time solution to this problem?
No. Sorry. Generally compile time code cannot interact with the system.
Well, we have string imports. Being able to walk the source tree doesn't look worse than being able to read files, no? But anyway, that was said with unknown modules. Imported modules are already known for module that imports them, right? So logically you don't need to interact with system, it's already just a part of your app.
Is it still impossible? Why?