www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - loop through specific class members

reply Trass3r <mrmocool gmx.de> writes:
Is there any way to loop through specific members of a class, e.g. all 
public functions?
I've already seen a function getMembers in druntime's ClassInfo class 
but I can't find anything related to the attributes there.
Jan 19 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Trass3r wrote:

 Is there any way to loop through specific members of a class, e.g. all
 public functions?
 I've already seen a function getMembers in druntime's ClassInfo class
 but I can't find anything related to the attributes there.


Assuming you're using D2, http://digitalmars.com/d/2.0/traits.html might
prove to be of interest.

  -- Daniel
Jan 19 2009
parent reply Trass3r <mrmocool gmx.de> writes:
Daniel Keep schrieb:

 Assuming you're using D2, http://digitalmars.com/d/2.0/traits.html might
 prove to be of interest.
 
   -- Daniel


It is indeed of interest though being not exactly what I want. Seems 
like there's currently no way to get attributes like public etc.

But I think an acceptable workaround would be to use a common name 
prefix for specific methods and then use that allMembers trait.
Jan 19 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Trass3r wrote:


 Daniel Keep schrieb:

 Assuming you're using D2, http://digitalmars.com/d/2.0/traits.html might
 prove to be of interest.
 
   -- Daniel


 
 It is indeed of interest though being not exactly what I want. Seems 
 like there's currently no way to get attributes like public etc.
 
 But I think an acceptable workaround would be to use a common name 
 prefix for specific methods and then use that allMembers trait.


Indeed, perhaps it should be there. You could use getVirtualFunctions to get
all public+protected member functions that are not declared final, but that's
not ideal. Another possible hack: if used from a different module, you could
use the 'compiles' trait with allMembers to find out if a member can be
accessed.
Jan 19 2009
parent reply BCS <ao pathlink.com> writes:
Reply to Lutger,


 Another possible hack: if used from a
 different module, you could use the 'compiles' trait with allMembers
 to find out if a member can be accessed.
 


you could define a template in another module that does the check and returns 
the result.
Jan 19 2009
parent reply Trass3r <mrmocool gmx.de> writes:
BCS schrieb:

 Reply to Lutger,
 

 Another possible hack: if used from a
 different module, you could use the 'compiles' trait with allMembers
 to find out if a member can be accessed.


 
 you could define a template in another module that does the check and 
 returns the result.
 
 


Well, it'd indeed be used from a different module than class, in fact 
from a different package.
But this only gives the public members, right?
Jan 19 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Trass3r wrote:

 BCS schrieb:

 Reply to Lutger,


 Another possible hack: if used from a
 different module, you could use the 'compiles' trait with allMembers
 to find out if a member can be accessed.


 you could define a template in another module that does the check and
 returns the result.


 
 Well, it'd indeed be used from a different module than class, in fact
 from a different package.
 But this only gives the public members, right?


It depends on what exactly you're trying to do.  Some time ago, I wrote
a library that created XML loaders for structs, and it needed to know
the names of fields.  Pre-traits, this is what I used:

struct Stuff
{
    int foo;
    char[] bar;

    alias Tuple!("foo", "bar") _fields;
}

Then I just looped over _fields.

  -- Daniel
Jan 19 2009
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Daniel,



 It depends on what exactly you're trying to do.  Some time ago, I
 wrote a library that created XML loaders for structs, and it needed to
 know the names of fields.  Pre-traits, this is what I used:
 
 struct Stuff
 {
 int foo;
 char[] bar;
 alias Tuple!("foo", "bar") _fields;
 }
 Then I just looped over _fields.
 
 -- Daniel
 


you can get the names even in D1.0. Not exactly clean but...

http://codepad.org/Eu16XqFu
Jan 19 2009
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
BCS wrote:

 Reply to Daniel,
 
 

 It depends on what exactly you're trying to do.  Some time ago, I
 wrote a library that created XML loaders for structs, and it needed to
 know the names of fields.  Pre-traits, this is what I used:

 struct Stuff
 {
 int foo;
 char[] bar;
 alias Tuple!("foo", "bar") _fields;
 }
 Then I just looped over _fields.

 -- Daniel


 
 you can get the names even in D1.0. Not exactly clean but...
 
 http://codepad.org/Eu16XqFu


I remember trying that, but abandoning it for some reason.  This code is
getting old now; over two years now, so that might not have worked back
then.

  -- Daniel
Jan 19 2009
prev sibling parent Trass3r <mrmocool gmx.de> writes:
BCS schrieb:

 you can get the names even in D1.0. Not exactly clean but...
 
 http://codepad.org/Eu16XqFu


Yeah but only works for structs. When used with classes returns an 
ExpressionTuple. Furthermore you only get the fields, I need the methods ;)
Jan 20 2009
prev sibling parent Trass3r <mrmocool gmx.de> writes:
Daniel Keep schrieb:

 Another possible hack: if used from a
 different module, you could use the 'compiles' trait with allMembers
 to find out if a member can be accessed.


 you could define a template in another module that does the check and
 returns the result.


 Well, it'd indeed be used from a different module than class, in fact
 from a different package.
 But this only gives the public members, right?


 
 It depends on what exactly you're trying to do.  Some time ago, I wrote
 a library that created XML loaders for structs, and it needed to know
 the names of fields.  Pre-traits, this is what I used:
 
 struct Stuff
 {
     int foo;
     char[] bar;
 
     alias Tuple!("foo", "bar") _fields;
 }
 
 Then I just looped over _fields.
 


What I want is a way that doesn't require much changes to the class 
itself but rather does the work in the module that actually uses the 
method names.

What I'm trying to do is providing a mechanism for LuaLib to register a 
whole class automatically (and probably also checking all method's 
parameters for correctness). So far you have to register each method to 
be used in lua individually.

So I was initially thinking about registering all protected methods or 
something like that. Guess I will use the prefix solution here cause it 
probably is the best way for this particular problem anyway.

But yet I'm interested in (and also somewhat impressed by) the 
possibilities to do this ;)


(reminds me of my search for a way to debug template and mixin stuff)
Jan 19 2009
prev sibling parent reply Trass3r <mrmocool gmx.de> writes:
It seems like there is no way to automatically get the class methods in 
D1 currently?!
__traits isn't supported, std.traits doesn't give anything usable, 
.tupleof only gets the fields (plus only giving an ExpressionTuple for 
classes).
Jan 20 2009
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Tue, Jan 20, 2009 at 10:29 AM, Trass3r <mrmocool gmx.de> wrote:

 It seems like there is no way to automatically get the class methods in D1
 currently?!
 __traits isn't supported, std.traits doesn't give anything usable, .tupleof
 only gets the fields (plus only giving an ExpressionTuple for classes).


You're correct.  __traits was introduced in D2 mostly because D1's
compile-time introspection is so paltry.
Jan 20 2009
next sibling parent reply Trass3r <mrmocool gmx.de> writes:
Jarrett Billingsley schrieb:

 On Tue, Jan 20, 2009 at 10:29 AM, Trass3r <mrmocool gmx.de> wrote:

 It seems like there is no way to automatically get the class methods in D1
 currently?!
 __traits isn't supported, std.traits doesn't give anything usable, .tupleof
 only gets the fields (plus only giving an ExpressionTuple for classes).


 
 You're correct.  __traits was introduced in D2 mostly because D1's
 compile-time introspection is so paltry.


Yeah, __traits works quite well to get the function names, but I still 
can't manage to get the corresponding function object to pass it to 
ParameterTypeTuple (for checking the parameters for correctness).

Tried using ClassInfo's getMembers function but that apparently doesn't 
work.

Base base = new Base;
auto members = __traits(allMembers, typeof(base));
foreach(m; members)
	writefln(base.classinfo.getMembers(m).length);

gives 0 for every member :(
Jan 20 2009
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Tue, Jan 20, 2009 at 2:13 PM, Trass3r <mrmocool gmx.de> wrote:

 Yeah, __traits works quite well to get the function names, but I still can't
 manage to get the corresponding function object to pass it to
 ParameterTypeTuple (for checking the parameters for correctness).


Ah, that's what __traits(getMember) is for.  You pass it an
object/class and a string of the member name, and it gives you what it
corresponds to.


 Tried using ClassInfo's getMembers function but that apparently doesn't
 work.

 Base base = new Base;
 auto members = __traits(allMembers, typeof(base));
 foreach(m; members)
        writefln(base.classinfo.getMembers(m).length);

 gives 0 for every member :(


I think that's actually a bug.  DMD doesn't generate that info for
some reason.  I think LDC does.
Jan 20 2009
parent Trass3r <mrmocool gmx.de> writes:
Jarrett Billingsley schrieb:

 On Tue, Jan 20, 2009 at 2:13 PM, Trass3r <mrmocool gmx.de> wrote:

 Yeah, __traits works quite well to get the function names, but I still can't
 manage to get the corresponding function object to pass it to
 ParameterTypeTuple (for checking the parameters for correctness).


 
 Ah, that's what __traits(getMember) is for.  You pass it an
 object/class and a string of the member name, and it gives you what it
 corresponds to.
 


OMG, I've already seen this function in the docs some time ago but 
somehow I couldn't remember.
Many thanks!
Jan 20 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Jarrett Billingsley wrote:

 On Tue, Jan 20, 2009 at 10:29 AM, Trass3r <mrmocool gmx.de> wrote:

 It seems like there is no way to automatically get the class methods in D1
 currently?!
 __traits isn't supported, std.traits doesn't give anything usable, .tupleof
 only gets the fields (plus only giving an ExpressionTuple for classes).


 
 You're correct.  __traits was introduced in D2 mostly because D1's
 compile-time introspection is so paltry.


But unless you're doing very basic stuff or only touching a few classes, 
compile-time introspection ends up being quite costly. I want runtime 
reflection for that reason.

On the other hand, you can get the non-final, non-private methods of a 
class with something like:
foreach (member; __traits (allMembers, Class))
{
	foreach (overload; __traits (getVirtualFunctions, Class, member))
	{
		// do stuff
	}
}

Naturally, __traits and foreach don't mix, so you'll have to use 
template recursion. This is pretty damn ugly.

Note that getVirtualFunctions returns methods that are not virtual. You 
need to use isVirtualFunction to determine whether a method is virtual.
Jan 20 2009
next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jan 20, 2009 at 7:42 PM, Christopher Wright <dhasenan gmail.com> wrote:


 Naturally, __traits and foreach don't mix, so you'll have to use template
 recursion. This is pretty damn ugly.


I never understood why __traits likes returning arrays so much.  Why not tuples?


 Note that getVirtualFunctions returns methods that are not virtual. You need
 to use isVirtualFunction to determine whether a method is virtual.


Lol.
Jan 20 2009
prev sibling parent reply Trass3r <mrmocool gmx.de> writes:
Christopher Wright schrieb:

 On the other hand, you can get the non-final, non-private methods of a 
 class with something like:
 foreach (member; __traits (allMembers, Class))
 {
     foreach (overload; __traits (getVirtualFunctions, Class, member))
     {
         // do stuff
     }
 }
 
 Naturally, __traits and foreach don't mix, so you'll have to use 
 template recursion. This is pretty damn ugly.
 


But why doesn't that work? It doesn't even work when forced to run at 
compile time by CTFE.
Had a look at the compiler code, it uses the same mechanism as 
pragma(msg, for example, so shouldn't something like the above 
theoretically be possible?
Jan 21 2009
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Wed, 21 Jan 2009 12:48:07 +0100, Trass3r wrote:


 Christopher Wright schrieb:

 On the other hand, you can get the non-final, non-private methods of a 
 class with something like:
 foreach (member; __traits (allMembers, Class))
 {
     foreach (overload; __traits (getVirtualFunctions, Class, member))
     {
         // do stuff
     }
 }
 
 Naturally, __traits and foreach don't mix, so you'll have to use 
 template recursion. This is pretty damn ugly.
 


 
 But why doesn't that work? It doesn't even work when forced to run at 
 compile time by CTFE.
 Had a look at the compiler code, it uses the same mechanism as 
 pragma(msg, for example, so shouldn't something like the above 
 theoretically be possible?


foreach() is a runtime construct.  It may be *interpreted* at
compile-time, but it's interpreted as if it were run time nevertheless.
It dynamically changes the value of 'member' variable.

pragma() and __traits() are compile-time constructs.  They are fully and
statically expanded before anything is being interpreted and cannot
handle dynamically changing variables.
Jan 25 2009
parent reply BCS <none anon.com> writes:
Hello Sergey,


 foreach() is a runtime construct.  It may be *interpreted* at
 compile-time, but it's interpreted as if it were run time
 nevertheless. It dynamically changes the value of 'member' variable.


OTOH a foreach on a tuple is a compile time construct, but it is a distinct 
construct from the array foreach and is not what you are using (If i'm reading 
stuff correctly)
Jan 25 2009
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 26 Jan 2009 04:50:10 +0000 (UTC), BCS wrote:


 Hello Sergey,
 

 foreach() is a runtime construct.  It may be *interpreted* at
 compile-time, but it's interpreted as if it were run time
 nevertheless. It dynamically changes the value of 'member' variable.


 
 OTOH a foreach on a tuple is a compile time construct, but it is a distinct 
 construct from the array foreach and is not what you are using (If i'm reading 
 stuff correctly)


I somehow missed that in the specs.  Definitely, this works:

template Tuple(T...)
{
  alias T Tuple;
}
void foo()
{
  foreach (a; Tuple!(int, char, long))
    pragma(msg, a.stringof);
}

but this doesn't:

template Tuple(T...)
{
  alias T Tuple;
}
void foo()
{
  foreach (a; Tuple!("a", "b", "c"))
    pragma(msg, a);
}

$ dmd -c test.d
test.d(8): Error: string expected for message, not 'a'
test.d(8): Error: string expected for message, not 'a'
test.d(8): Error: string expected for message, not 'a'

*This* seems like a bug to me.
Jan 26 2009
parent reply BCS <none anon.com> writes:
Hello Sergey,


 but this doesn't:
 
 template Tuple(T...)
 {
 alias T Tuple;
 }
 void foo()
 {
 foreach (a; Tuple!("a", "b", "c"))
 pragma(msg, a);
 }
 $ dmd -c test.d
 test.d(8): Error: string expected for message, not 'a'
 test.d(8): Error: string expected for message, not 'a'
 test.d(8): Error: string expected for message, not 'a'
 *This* seems like a bug to me.
 


try indexing it:

template Tuple(T...)
{
 alias T Tuple;
}
void foo()
{
 alias Tuple!("a", "b", "c") Tpl;
 foreach (i,a; Tpl)
  pragma(msg, Tpl[i]);
}

(BTW that is a known bug)
Jan 26 2009
parent Trass3r <mrmocool gmx.de> writes:
BCS schrieb:

 Hello Sergey,
 

 but this doesn't:

 template Tuple(T...)
 {
 alias T Tuple;
 }
 void foo()
 {
 foreach (a; Tuple!("a", "b", "c"))
 pragma(msg, a);
 }
 $ dmd -c test.d
 test.d(8): Error: string expected for message, not 'a'
 test.d(8): Error: string expected for message, not 'a'
 test.d(8): Error: string expected for message, not 'a'
 *This* seems like a bug to me.


 
 try indexing it:
 
 template Tuple(T...)
 {
 alias T Tuple;
 }
 void foo()
 {
 alias Tuple!("a", "b", "c") Tpl;
 foreach (i,a; Tpl)
  pragma(msg, Tpl[i]);
 }
 
 (BTW that is a known bug)
 


Do you know the bug number?
Mar 29 2009