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?

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

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

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.

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.

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.