Thread overview
List classes at compile time
3 days ago
Noé Falzon
3 days ago
evilrat
1 day ago
Noé Falzon
3 days ago

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?

3 days ago

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.

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

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
...

1 day ago

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.