fix Issue 23558 - add __traits(getModuleClasses [, module name])

[WalterBright]

Provide alternative to Object.factory(), see #14681

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	23558	enhancement	add __traits(getModuleClasses [, module name])

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#14699"

[rikkimax]

I have to say, I'm not convinced by this approach for a couple of reasons. A filter approach that is more generic would be far better. __traits(getMembers, symbolOrModule, function/class/struct/union/field) would be a lot more useful and allow simplifying significant existing logic.

Use cases: registration of web routes, ORM's, CLI handling.

[WalterBright]

See also: https://www.digitalmars.com/d/archives/digitalmars/D/ModuleInfo_Object.localClasses_and_Object.find_-_any_users_366643.html

[WalterBright]

@rikkimax if you or anyone else want to write this function, please do so!

[rikkimax]

Traits at least are something I can do, so yeah it can go on the back burner after the refactor in dub to output a list of modules. Just a shame that we are introducing an ultra-specific trait when we know a more generic one will come eventually ;)

[WalterBright]

There's not much point in doing a spec PR until this is approved.

[rikkimax]

@rikkimax if you or anyone else want to write this function, please do so!

https://issues.dlang.org/show_bug.cgi?id=23559

[ibuclaw]

But this trait won't work in the same way as the current runtime moduleinfo equivalent, will it?

pragma(msg, __traits(getModuleClasses));  // A? 
static if (cond) class B {} 
pragma(msg, __traits(getModuleClasses)); // A, B? 
class A { } 
enum cond = true;

The above is only for illustration, there are likely better/actual examples where traits produce different results depending on ordering (a traits inside a struct members list), but I don't have a compiler to test at the moment.

[WalterBright]

It produces:

tuple("B", "test2.A")
tuple("B", "test2.A")

[WalterBright]

This works as is, but will have to be changed when #14708 is merged.

[RazvanN7]

@WalterBright could you maybe add a changelog entry + a spec PR?

[RazvanN7]

Needs changelog entry.

added changelog

[WalterBright]

@RazvanN7 ready to go

[adamdruppe]

@rikkimax if you or anyone else want to write this function, please do so!

This has been done by several D programmers. It is an utterly trivial loop over the existing traits(allMembers).

[schveiguy]

This gives you the actual types (which is more useful). I wrote it in 5 minutes.

template AllClasses(alias mod) {
   import std.meta : AliasSeq;
   alias result = AliasSeq!();
   static foreach(m; __traits(allMembers, mod))
      static if(is(__traits(getMember, mod, m) == class))
         result = AliasSeq!(result, __traits(getMember, mod, m));
   alias AllClasses = result;
}

[WalterBright]

Thank you, @schveiguy

The idea is to replace the Object.factory and Typeinfo_Class.find functions that rely on ModuleInfo. If you want to do a better PR with your code, please do.

[schveiguy]

My point was just that the trait you created is not necessary, and in fact, not very helpful. It's hard to turn a string into a type, even when you know the module it comes from (unless you want to use __traits(getMember), but you can't do that with this trait). The reason Object.factory works is because the compiler registers the types -- the strings are just used for lookup, and arbitrarily whatever the typeinfo decides to use, the important part that is needed is the storage of all the types. How do you plan to solve that?

What is needed is a complete solution of how to create a registration system. Ideally at compile-time, but if not, at least at runtime (keeping in mind that static constructors cannot be used as they add cycles to complex code).

[adamdruppe]

Let's revert this now before the useless baggage actually makes it into a release.