digitalmars.D - type testing issues
- derick_eddington nospam.yashmoo.com (13/13) May 30 2005 If this has been discussed before please point me to it.
- Andrew Fedoniouk (5/24) May 30 2005 Is the Thing class or POD type?
- derick_eddington nospam.yashmoo.com (6/35) May 30 2005 A class. I know you can do more involved stuff with classinfos and type...
- Sean Kelly (7/20) May 30 2005 I'm currently using identity comparison, as D DLL support is mostly theo...
- derick_eddington nospam.yashmoo.com (5/30) May 30 2005 Fully-qualified ClassInfo.name would be cool, but the documentation impl...
- John Demme (7/26) May 30 2005 I'm not certain if this works properly for structs, but when I'm dealing
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
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
derick_eddington nospam.yashmoo.com 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
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
In article <d7fft1$2ffk$1 digitaldaemon.com>, Sean Kelly says...In article <d7ef11$1c4f$1 digitaldaemon.com>, derick_eddington nospam.yashmoo.com says...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.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
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