www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - TypeInfo_Class.interfaces[n].classinfo has TypeInfo_Class and not

reply Tofu Ninja <joeyemmons yahoo.com> writes:
I didn't get any response in learn for this so I will ask it here.

TypeInfo_Class.interfaces[n].classinfo has TypeInfo_Class and not 
TypeInfo_Interface?

Is this correct? Or is it a bug?
Doesn't make much sense to me.

Also the following code prints false so there are some 
consequences to this.

import std.stdio;
void main(string[] args) {
	writeln(typeid(c).interfaces[0].classinfo == typeid(i)); // false
}
interface i {}
class c : i {}

What is the proper way to handle this mismatch?
Is this mismatch intended or just some implementation detail?
Peoples thoughts on this?
Dec 23 2017
parent reply Tofu Ninja <joeyemmons yahoo.com> writes:
On Sunday, 24 December 2017 at 05:21:44 UTC, Tofu Ninja wrote:
 I didn't get any response in learn for this so I will ask it 
 here.

 TypeInfo_Class.interfaces[n].classinfo has TypeInfo_Class and 
 not TypeInfo_Interface?

 Is this correct? Or is it a bug?
 Doesn't make much sense to me.

 Also the following code prints false so there are some 
 consequences to this.

 import std.stdio;
 void main(string[] args) {
 	writeln(typeid(c).interfaces[0].classinfo == typeid(i)); // 
 false
 }
 interface i {}
 class c : i {}

 What is the proper way to handle this mismatch?
 Is this mismatch intended or just some implementation detail?
 Peoples thoughts on this?
I guess I will just not get an answer to this, seems like just some weirdness of D that will just stick there. The typeinfo system seems really half baked and really provides very little in terms of usefulness.
Dec 27 2017
next sibling parent rjframe <dlang ryanjframe.com> writes:
On Wed, 27 Dec 2017 23:28:27 +0000, Tofu Ninja wrote:

 On Sunday, 24 December 2017 at 05:21:44 UTC, Tofu Ninja wrote:
 
 I guess I will just not get an answer to this, seems like just some
 weirdness of D that will just stick there. The typeinfo system seems
 really half baked and really provides very little in terms of
 usefulness.
What are you trying to do? Will std.traits.InterfacesTuple[1] or BaseTypeTuple[2] do what you need? [1]: https://dlang.org/phobos/std_traits.html#.InterfacesTuple [2]: https://dlang.org/phobos/std_traits.html#.BaseTypeTuple
Dec 27 2017
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/27/17 6:28 PM, Tofu Ninja wrote:
 On Sunday, 24 December 2017 at 05:21:44 UTC, Tofu Ninja wrote:
 I didn't get any response in learn for this so I will ask it here.

 TypeInfo_Class.interfaces[n].classinfo has TypeInfo_Class and not 
 TypeInfo_Interface?

 Is this correct? Or is it a bug?
 Doesn't make much sense to me.

 Also the following code prints false so there are some consequences to 
 this.

 import std.stdio;
 void main(string[] args) {
     writeln(typeid(c).interfaces[0].classinfo == typeid(i)); // false
 }
 interface i {}
 class c : i {}

 What is the proper way to handle this mismatch?
 Is this mismatch intended or just some implementation detail?
 Peoples thoughts on this?
I guess I will just not get an answer to this, seems like just some weirdness of D that will just stick there. The typeinfo system seems really half baked and really provides very little in terms of usefulness.
I'm not even sure why TypeInfo_Interface exists. It seems to be a thin wrapper over its TypeInfo_Class member `info`. TypeInfo_Class itself has an overridable `info` member which is never overridden, so I'm not sure what the purpose of that is either. Looking at the implementation of TypeInfo_Interface, it appears that the only reason to have it, is to allow using interfaces as hash keys. But the blunt casting there, I don't think is right. Not all interfaces can be cast to Object. I'll note that opEquals is also implemented incorrectly. IMO, TypeInfo_Interface should be derived from TypeInfo_Class, and simply override the equals/getHash/compare functions. Then change the type of 'classinfo' inside the Interface struct to TypeInfo_Interface. The compiler needs to be updated for this of course. So in short, I think there are bugs here, but probably not what you expected. -Steve
Dec 30 2017