If this has been discussed before please point me to it.

Can't use (someTypeInfo == typeid(Thing)) because all Objects will pass (see my
thread in digitalmars.D.learn).

Can't rely on (someTypeInfo is typeid(Thing)) because duplicate TypeInfos for
the same type can exist (per Walter's comments in phobos/internal/object.d).

Can't rely on (someTypeInfo.toString == typeid(Thing).toString) because toString
does not give the fully qualified name.  blah.Thing and acme.Thing will both
pass when you only want one.

How is one supposed to test types with certainty?  From a language-attractiveness perspective, requiring anything more involved than (someTypeInfo == typeid(Thing)) turns me way off.  From the very limited contents about typeid and TypeInfo in the documentation, it seems this simplicity was the goal.

Is the Thing class or POD type?
If it is class then you can play with classinfo rather than typeinfo.

Andrew.


<derick_eddington@nospam.yashmoo.com> wrote in message news:d7ef11$1c4f$1@digitaldaemon.com...
> If this has been discussed before please point me to it.
>
> Can't use (someTypeInfo == typeid(Thing)) because all Objects will pass
> (see my
> thread in digitalmars.D.learn).
>
> Can't rely on (someTypeInfo is typeid(Thing)) because duplicate TypeInfos
> for
> the same type can exist (per Walter's comments in
> phobos/internal/object.d).
>
> Can't rely on (someTypeInfo.toString == typeid(Thing).toString) because
> toString
> does not give the fully qualified name.  blah.Thing and acme.Thing will
> both
> pass when you only want one.
>
> How is one supposed to test types with certainty?  From a language-attractiveness perspective, requiring anything more involved than (someTypeInfo == typeid(Thing)) turns me way off.  From the very limited contents about typeid and TypeInfo in the documentation, it seems this simplicity was the goal.
>
> 

In article <d7ef11$1c4f$1@digitaldaemon.com>, derick_eddington@nospam.yashmoo.com says...
>
>If this has been discussed before please point me to it.
>
>Can't use (someTypeInfo == typeid(Thing)) because all Objects will pass (see my
>thread in digitalmars.D.learn).
>
>Can't rely on (someTypeInfo is typeid(Thing)) because duplicate TypeInfos for
>the same type can exist (per Walter's comments in phobos/internal/object.d).
>
>Can't rely on (someTypeInfo.toString == typeid(Thing).toString) because toString
>does not give the fully qualified name.  blah.Thing and acme.Thing will both
>pass when you only want one.
>
>How is one supposed to test types with certainty?  From a language-attractiveness perspective, requiring anything more involved than (someTypeInfo == typeid(Thing)) turns me way off.  From the very limited contents about typeid and TypeInfo in the documentation, it seems this simplicity was the goal.

I'm currently using identity comparison, as D DLL support is mostly theoretical at this point.  In the long term though, I would expect the ClassInfo name to be the reliable source for comparison, as it should eventually contain the full mangled name for the type, correct?


Sean

I'm not certain if this works properly for structs, but when I'm dealing
with classes and interfaces, I'll use something like:
if (cast(MyClass)inst) { ... }
since cast will return null if the class can't be casted to that type.

John Demme

On Mon, 2005-05-30 at 07:23 +0000, derick_eddington@nospam.yashmoo.com wrote:
> If this has been discussed before please point me to it.
> 
> Can't use (someTypeInfo == typeid(Thing)) because all Objects will pass (see my
> thread in digitalmars.D.learn).
> 
> Can't rely on (someTypeInfo is typeid(Thing)) because duplicate TypeInfos for
> the same type can exist (per Walter's comments in phobos/internal/object.d).
> 
> Can't rely on (someTypeInfo.toString == typeid(Thing).toString) because toString
> does not give the fully qualified name.  blah.Thing and acme.Thing will both
> pass when you only want one.
> 
> How is one supposed to test types with certainty?  From a language-attractiveness perspective, requiring anything more involved than (someTypeInfo == typeid(Thing)) turns me way off.  From the very limited contents about typeid and TypeInfo in the documentation, it seems this simplicity was the goal.
> 
> 

In article <d7eg1n$1d9v$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>Is the Thing class or POD type?
>If it is class then you can play with classinfo rather than typeinfo.
>
>Andrew.

A class.  I know you can do more involved stuff with classinfos and typeinfos
and assume things about the internal TypeInfo class naming... but my main point
is needing to do anything more than (typeid(T1) == typeid(T2)) for all cases is
really annoying.

--Derick

>
>
><derick_eddington@nospam.yashmoo.com> wrote in message news:d7ef11$1c4f$1@digitaldaemon.com...
>> If this has been discussed before please point me to it.
>>
>> Can't use (someTypeInfo == typeid(Thing)) because all Objects will pass
>> (see my
>> thread in digitalmars.D.learn).
>>
>> Can't rely on (someTypeInfo is typeid(Thing)) because duplicate TypeInfos
>> for
>> the same type can exist (per Walter's comments in
>> phobos/internal/object.d).
>>
>> Can't rely on (someTypeInfo.toString == typeid(Thing).toString) because
>> toString
>> does not give the fully qualified name.  blah.Thing and acme.Thing will
>> both
>> pass when you only want one.
>>
>> How is one supposed to test types with certainty?  From a language-attractiveness perspective, requiring anything more involved than (someTypeInfo == typeid(Thing)) turns me way off.  From the very limited contents about typeid and TypeInfo in the documentation, it seems this simplicity was the goal.
>>
>> 
>
>

In article <d7fft1$2ffk$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <d7ef11$1c4f$1@digitaldaemon.com>, derick_eddington@nospam.yashmoo.com says...
>>
>>If this has been discussed before please point me to it.
>>
>>Can't use (someTypeInfo == typeid(Thing)) because all Objects will pass (see my
>>thread in digitalmars.D.learn).
>>
>>Can't rely on (someTypeInfo is typeid(Thing)) because duplicate TypeInfos for
>>the same type can exist (per Walter's comments in phobos/internal/object.d).
>>
>>Can't rely on (someTypeInfo.toString == typeid(Thing).toString) because toString
>>does not give the fully qualified name.  blah.Thing and acme.Thing will both
>>pass when you only want one.
>>
>>How is one supposed to test types with certainty?  From a language-attractiveness perspective, requiring anything more involved than (someTypeInfo == typeid(Thing)) turns me way off.  From the very limited contents about typeid and TypeInfo in the documentation, it seems this simplicity was the goal.
>
>I'm currently using identity comparison, as D DLL support is mostly theoretical at this point.  In the long term though, I would expect the ClassInfo name to be the reliable source for comparison, as it should eventually contain the full mangled name for the type, correct?
>
>
>Sean

Fully-qualified ClassInfo.name would be cool, but the documentation implies typeid() is the thing to use, and anything else is inconsistent with other languages well-established type-testing and I think will really throw prospective D users.