www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - typeid(SomeClass) == typeid(AnotherClass) -- what's the deal?

reply derick_eddington nospam.yashmoo.com writes:
For example, and this contradicts what
http://www.digitalmars.com/d/function.html variadic example with typeid(FOO)
implies:

: import std.stdio;
:
: class IWant {}
:
: class IDontWant {}
:
: void hmm (...)
: {
:       writefln("_arguments[0] = %s", _arguments[0]);
:
:       if (_arguments[0] == typeid(IWant)) {
:               writefln("_arguments[0] == typeid(IWant)");
:
:               if (_arguments[0] !== typeid(IWant))
:                       writefln("But (_arguments[0] !== typeid(IWant))");
:       }
:
: }
:
: void main ()
: {
:       hmm(new IDontWant);
: }

This is happening because internal/object.d/TypeInfo.opEquals(Object) does:

return this is o || this.classinfo.name == o.classinfo.name;

and typeid(IWant).classinfo.name == typeid(IDontWant).classinfo.name ==
"TypeInfo_Class"

Did the recent TypeInfo additions/changes? change the semantics and/or make the
type stuff more complex to use?

I came accross this trying to use, intuitively I thought, TypeInfo as the
key-type of a module-internal A.A. which I wanted to do
(typeid(UserSuppliedType) in MyAA) to check if that type is supported and go on
to use the MyAA[UserSuppliedType] value.  Other ideas not using an A.A. don't
seem plausible for the same reason and (typeid(SomeClass) is
typeid(AnotherClass)) can't be used because "TypeInfo instances are singletons,
but duplicates can exist across DLL's."

If you have to do lower-level intricate efforts, then the documentation should
not make it seem like the type stuff is simply and easily usable.

Is it going to get easier to use?  Is it going to be standardized accross
different D compilers?
May 29 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 30 May 2005 02:42:31 +0000 (UTC),
derick_eddington nospam.yashmoo.com wrote:

 For example, and this contradicts what
 http://www.digitalmars.com/d/function.html variadic example with typeid(FOO)
 implies:
 
: import std.stdio;
:
: class IWant {}
:
: class IDontWant {}
:
: void hmm (...)
: {
:       writefln("_arguments[0] = %s", _arguments[0]);
:
:       if (_arguments[0] == typeid(IWant)) {
:               writefln("_arguments[0] == typeid(IWant)");
:
:               if (_arguments[0] !== typeid(IWant))
:                       writefln("But (_arguments[0] !== typeid(IWant))");
:       }
:
: }
:
: void main ()
: {
:       hmm(new IDontWant);
: }
 
 This is happening because internal/object.d/TypeInfo.opEquals(Object) does:
 
 return this is o || this.classinfo.name == o.classinfo.name;
 
 and typeid(IWant).classinfo.name == typeid(IDontWant).classinfo.name ==
 "TypeInfo_Class"

For what its worth, you can use ... if (_arguments[0].toString == typeid(IWant).toString) -- Derek Melbourne, Australia 30/05/2005 1:33:46 PM
May 29 2005
parent reply derick_eddington nospam.yashmoo.com writes:
In article <158z7o8qiu9ci.1qrko1jfaxi6t$.dlg 40tude.net>, Derek Parnell says...
For what its worth, you can use ...

   if (_arguments[0].toString == typeid(IWant).toString)

Thanks, this helps.
May 29 2005
parent derick_eddington nospam.yashmoo.com writes:
In article <d7e9ce$14t4$1 digitaldaemon.com>,
derick_eddington nospam.yashmoo.com says...
In article <158z7o8qiu9ci.1qrko1jfaxi6t$.dlg 40tude.net>, Derek Parnell says...
For what its worth, you can use ...

   if (_arguments[0].toString == typeid(IWant).toString)

Thanks, this helps.

Though, it's not robust; which I'm sure you know but just to comment... If I have: mine.d ------------------------ class GenericName {} and somebody else makes: theirs.d --------------------- class GenericName {} and the possible situation they both could be used in something like: typeid(mine.GenericName).toString == _arguments[0].toString; they'll both pass, which is definitely not what you'd want.
May 29 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 30 May 2005 02:42:31 +0000 (UTC),
derick_eddington nospam.yashmoo.com wrote:

 For example, and this contradicts what
 http://www.digitalmars.com/d/function.html variadic example with typeid(FOO)
 implies:
 
: import std.stdio;
:
: class IWant {}
:
: class IDontWant {}
:
: void hmm (...)
: {
:       writefln("_arguments[0] = %s", _arguments[0]);

Note that writefln() calls _arguments[0].toString here.
:       if (_arguments[0] == typeid(IWant)) {

I suspect that you should saying ... if (_arguments[0] is typeid(IWant)) {
:               writefln("_arguments[0] == typeid(IWant)");
:
:               if (_arguments[0] !== typeid(IWant))
:                       writefln("But (_arguments[0] !== typeid(IWant))");
:       }
:
: }
:
: void main ()
: {
:       hmm(new IDontWant);
: }
 
 This is happening because internal/object.d/TypeInfo.opEquals(Object) does:
 
 return this is o || this.classinfo.name == o.classinfo.name;
 
 and typeid(IWant).classinfo.name == typeid(IDontWant).classinfo.name ==
 "TypeInfo_Class"

Is this really strange? As far as I see it, typeid() returns an instance of a TypeInfo class. And thus the class name of TypeInfo is "TypeInfo_Class". -- Derek Melbourne, Australia 30/05/2005 2:01:35 PM
May 29 2005
parent derick_eddington nospam.yashmoo.com writes:
In article <12o2n6f2q6u4m$.erho76iv4mzy$.dlg 40tude.net>, Derek Parnell says...
:       writefln("_arguments[0] = %s", _arguments[0]);

Note that writefln() calls _arguments[0].toString here.

Right, I did that intentionally to see .toString to differentiate different classes when I was playing around with it before I posted that...
:       if (_arguments[0] == typeid(IWant)) {

I suspect that you should saying ... if (_arguments[0] is typeid(IWant)) {

But duplicates can exist accross DLLs so you can't rely on it. I used 'is' in my example in the other place because it's only one simple executable.
 
 This is happening because internal/object.d/TypeInfo.opEquals(Object) does:
 
 return this is o || this.classinfo.name == o.classinfo.name;
 
 and typeid(IWant).classinfo.name == typeid(IDontWant).classinfo.name ==
 "TypeInfo_Class"

Is this really strange? As far as I see it, typeid() returns an instance of a TypeInfo class. And thus the class name of TypeInfo is "TypeInfo_Class".

The name makes perfect sense; the problem I see is what TypeInfo.opEquals is doing that causes typeid(SomeClass) == typeid(AnotherClass), which is hardly intuitive and totally undocumented along with all the other intricacies of D type stuff.
May 29 2005