www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - type testing issues

reply derick_eddington nospam.yashmoo.com writes:
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.
May 30 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
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.

 

May 30 2005
parent derick_eddington nospam.yashmoo.com writes:
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.

 


May 30 2005
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
May 30 2005
parent derick_eddington nospam.yashmoo.com writes:
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.
May 30 2005
prev sibling parent John Demme <me teqdruid.com> writes:
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.
 
 

May 30 2005