TTypeID.ForObject( ).name() returns abstract name

BlitzMax Forums/BlitzMax Programming/TTypeID.ForObject( ).name() returns abstract name

beanage

(Posted 2009) [#1]

Hey,

I have an error, which I cant really get my head around..

Consider this scenario:

Type MyAbstractType Abstract
End Type

Type MyInheritingType Extends MyAbstractType
End Type

Local MyObject:MyInheritingType = New MyInheritingType
Print "class= "+TTypeID.ForObject( MyObject ).name()

This should output "class= MyInheritingType", shouldnt it? [And it does, as Htbaa proved below.]

My Problem: I have code of mine returning the name of an abstract type!?
How can that happen?
Any Ideas?

I know you can create objects of abstract types via reflection, but I am sure I dont do.

Htbaa

(Posted 2009) [#2]

Building untitled1
Compiling:untitled1.bmx
flat assembler  version 1.68  (1653550 kilobytes memory)
3 passes, 4243 bytes.
Linking:untitled1.debug.mt.exe
Executing:untitled1.debug.mt.exe
class= MyInheritingType

Process complete

Works fine. What version of Blitzmax are you using?

beanage

(Posted 2009) [#3]

Uh, I use BlitzMax 1.36, normal-threaded built.

Of course that code I wrote there works fine, because I just wanted to cut a long story short by writing it. It's not the actual code I use (which is 200 times longer).

My question was:
What circumstances could lead to the reflection outputting an abstract type's name for an object that is actually of a none-abstract type?

Kurator

(Posted 2009) [#4]

Srry, I have no current installation of BMax running, but:

Does this maybe happen when you write:

Local MyObject:MyAbstractType = New MyInheritingType

Azathoth

(Posted 2009) [#5]

Are you sure you haven't some how got the super class?

Htbaa

(Posted 2009) [#6]

Kurator's suggestion is most likely your problem.

Azathoth

(Posted 2009) [#7]

What Kurator said doesn't happen due to polymorphism.

Edit: MyObject points to an instance of MyInheritingType even though its declared as MyAbstractType.

N	(Posted 2009) [#8]

What circumstances could lead to the reflection outputting an abstract type's name for an object that is actually of a none-abstract type?

Horrible mistakes - including, but not limited to, unintentionally overwriting the clas member of the object, instantiating the abstract member, etc.

Edit: It may also be possible that the info stored by the reflection module was somehow modified/corrupted (not the data that the module uses to get the info, just the info itself).

Kurator

(Posted 2009) [#9]

Yes, Azathoth is right, there must be another bug in your code, I guess Niliums hints are a good tip to begin searching :)

Mahan

(Posted 2009) [#10]

I once encountered something similar. When inheriting from a class and using reflection inside the constructor of a child class it seemed as the type at that point actually was the parent class.

If I moved the reflection outside the constructor (after the child-class was instanced) everything was alright and the TTypeInfo was correct for the child class.

I didn't investigate further back then, but I just wanted to mention this as this might be the same or a very similar problem.

N	(Posted 2009) [#11]

Using reflection in a constructor is also a bad idea. Does the instance you're creating have code in the constructor of its abstract superclass to get the TTypeID of itself?