www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - List classes at compile time

reply =?UTF-8?B?Tm/DqQ==?= Falzon <falzon.noe gmail.com> writes:
tl;dr: is it possible to iterate over all classes in a program at 
compile time (or possibly all derived classes from a given base 
class) to use in a mixin?

Longer version:

Hi! I'm essentially trying to select which class to 
instantiate/use as template argument based on a runtime string 
(user provided). Something like:

```
string s = args[1];
if (s == "foo") { import foo; return Driver!Foo.run(); }
if (s == "bar") { import bar; return Driver!Bar.run(); }
if (s == "baz") { import baz; return Driver!Baz.run(); }
...
```

Using mixins, I managed to reduce this to:

```
static foreach(name; ["Foo", "Bar", "Baz"])
{
mixin(iq{
if (s == "$(name.toLower)")
   {
     import $(name.toLower);
     return Driver!$(name).run();
   }
}.text);
}
```

But it would be even nicer not to have to list the classes by 
hand, of course (there might be hundreds eventually).

The closest I got so far is to generate the list of names with a 
pre-build command that greps through the sources for relevant 
class names, and a file import:

```
const names = import("names.csv").split(",");
```

But that feels like cheating, and it's of course error-prone 
since it's text based. Also, if I'm going to run a pre-build 
command, I might as well just generate the boilerplate source 
code there and just compile the file directly.

Would there a cleaner, D-like way to achieve this? Or a 
completely different approach to the problem?
Oct 19
parent reply evilrat <evilrat666 gmail.com> writes:
On Saturday, 19 October 2024 at 08:51:20 UTC, NoƩ Falzon wrote:
 tl;dr: is it possible to iterate over all classes in a program 
 at compile time (or possibly all derived classes from a given 
 base class) to use in a mixin?
No, parent class can not possibly know who extends it, just think about dynamic libraries... And unfortunately there is no single place to know every possible module used in a build for various reasons, the closest thing you can do is obtain modules present in a separate compilation unit, i.e. a module with its imports. as seen with 'dummy' module parent, you cannot get above it. in this case dummy module is here, but if for example I also had another module I can't access it this way without importing it some way or another. ```d import std.stdio; import std.algorithm; import dummy; enum foo = "we need foo just to get something accessible in this module"; pragma(msg, __traits(allMembers, __traits(parent, foo))); // prints AliasSeq!("object", "std", "dummy", "foo") //pragma(msg, __traits(allMembers, __traits(parent, dummy))); // Error: argument `dummy` has no parent ```
 The closest I got so far is to generate the list of names with 
 a pre-build command that greps through the sources for relevant 
 class names, and a file import:
The only improvement to this I can think of is to use D AST parser that reliably understands code structure. The example of this you can find in godot-d class finder, other than that it works exactly same. https://github.com/godot-dlang/godot-dlang/blob/534024c7e27522d6120a9b64e8ef183b79416539/modules/tools/classfinder/godot/tools/classfinder/package.d Just in case, there is a possible way to get modules at RUNTIME, and from there ModuleInfo has list of classes and other type information. https://dlang.org/phobos/object.html#.ModuleInfo.localClasses ```d import std.stdio; void main() { // ModuleInfo without parenthesis will call opDelegate to acquire list of modules known at runtime foreach(m; ModuleInfo) { writeln(m.name); } } ``` prints rt.lifetime rt.dmain2 core.internal.gc.proxy rt.deh_win64_posix core.exception ...
Oct 19
parent =?UTF-8?B?Tm/DqQ==?= Falzon <falzon.noe gmail.com> writes:
Thank you for the detailed answer! I will look into feasibility 
at runtime, or I'll default back to generating the list 
programmatically to feed into the mixin.
Oct 21