• Tofu Ninja (15/15) Apr 13 2013 Currently is there a way to get all of the subclasses of a class
• Andrej Mitrovic (6/8) Apr 13 2013 There might be things like using .moduleinfo and traversing imports to
• Namespace (3/18) Apr 13 2013 Maybe this is helpfully:
• Tofu Ninja (1/3) Apr 13 2013 Oddly enough, I found that at about the same time you posted it.
• Tofu Ninja (2/5) Apr 13 2013 Sadly this does not provide a compile time solution, only runtime.
• Benjamin Thaut (6/12) Apr 14 2013 Do you need all derived classes or or only all derived classes within
• Alex (4/12) Mar 29 2019 I wonder if one could use this to first spawn a process at

"Tofu Ninja" <emmons0 purdue.edu> writes:

Currently is there a way to get all of the subclasses of a class 
at compile time?
It seems like something that should be possible using traits but 
I can't seems to see how.

Something like

class A{...}
class B:A{...}
class C:A{...}

...

foreach(auto t ; getsubclass(A))
{
    ...
}

Any help would be grateful.
Tofu

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 4/13/13, Tofu Ninja <emmons0 purdue.edu> wrote:
 Currently is there a way to get all of the subclasses of a class
 at compile time?

There might be things like using .moduleinfo and traversing imports to
find all classes, but I think separate compilation makes this
unreliable.

There is however BaseClassTuple in std.traits, so you can pass a leaf
class to get the class hierarchy.

"Namespace" <rswhite4 googlemail.com> writes:

On Saturday, 13 April 2013 at 16:16:03 UTC, Tofu Ninja wrote:
 Currently is there a way to get all of the subclasses of a 
 class at compile time?
 It seems like something that should be possible using traits 
 but I can't seems to see how.

 Something like

 class A{...}
 class B:A{...}
 class C:A{...}

 ...

 foreach(auto t ; getsubclass(A))
 {
    ...
 }

 Any help would be grateful.
 Tofu

Maybe this is helpfully:
http://forum.dlang.org/thread/scgjnudclnwlbdqqdsyn forum.dlang.org

"Tofu Ninja" <emmons0 purdue.edu> writes:

 Maybe this is helpfully:
 http://forum.dlang.org/thread/scgjnudclnwlbdqqdsyn forum.dlang.org

Oddly enough, I found that at about the same time you posted it.

"Tofu Ninja" <emmons0 purdue.edu> writes:

On Saturday, 13 April 2013 at 17:45:12 UTC, Tofu Ninja wrote:
 Maybe this is helpfully:
 http://forum.dlang.org/thread/scgjnudclnwlbdqqdsyn forum.dlang.org

 Oddly enough, I found that at about the same time you posted it.

Sadly this does not provide a compile time solution, only runtime.

Benjamin Thaut <code benjamin-thaut.de> writes:

Am 13.04.2013 19:49, schrieb Tofu Ninja:
 On Saturday, 13 April 2013 at 17:45:12 UTC, Tofu Ninja wrote:
 Maybe this is helpfully:
 http://forum.dlang.org/thread/scgjnudclnwlbdqqdsyn forum.dlang.org

 Oddly enough, I found that at about the same time you posted it.

 Sadly this does not provide a compile time solution, only runtime.

Do you need all derived classes or or only all derived classes within 
one module? Because the former is most likely impossible because it 
would break the compilation model.

Kind Regards
Benjamin Thaut

Alex <AJ gmail.com> writes:

On Saturday, 13 April 2013 at 17:50:00 UTC, Tofu Ninja wrote:
 On Saturday, 13 April 2013 at 17:45:12 UTC, Tofu Ninja wrote:
 Maybe this is helpfully:
 http://forum.dlang.org/thread/scgjnudclnwlbdqqdsyn forum.dlang.org

 Oddly enough, I found that at about the same time you posted 
 it.

 Sadly this does not provide a compile time solution, only 
 runtime.

I wonder if one could use this to first spawn a process at 
compile type and then spit out the information and then process 
that info at compile time(say from a text file).