• Vladimir Marchevsky (24/30) Apr 09 Practical example: some framework allows it's user to define

Vladimir Marchevsky <vladimmi gmail.com> writes:

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?