An extended type can change variable types?

BlitzMax Forums/BlitzMax Programming/An extended type can change variable types?

Picklesworth

(Posted 2007) [#1]

This kind of makes sense in a way I can't quite put my finger on...

Strict

Type MainTypeData
	Field name:String="MainType"
End Type

Type ChildTypeData
	Field name:String="ChildType"
	Field iamdifferent:String="I am different!"
End Type

Type MainType
	Field data:MainTypeData=New MainTypeData
	
	Field bleh:Int=4
End Type

Type ChildType Extends MainType
	Field data:ChildTypeData=New ChildTypeData
	
	Field bleh:Float=4.51
End Type

Local Main:MainType=New MainType
Local Child:ChildType=New ChildType

WriteStdout(Main.data.name+" bleh is ")
WriteStdout(Main.bleh+"~n")
WriteStdout(Child.data.name+" bleh is ")
WriteStdout(Child.bleh+"~n")

End

What I think I'm doing here is giving an overrided type a different return type than its parent. This is good (excellent for my purposes!) but kind of surprised me.
Why can I override the type of a variable by extending, but not the return type of a method?

With this in mind, I am probably very confused about a lot of things...

FlameDuck

(Posted 2007) [#2]

It doesn't. You're creating a NEW Field with the same name, which is something you can do, because it's a different scope. If you're relying on Polymorphism it's almost certainly going to screw up.

WriteStdout(Main.data.name+" bleh is ")
WriteStdout(Main.bleh+"~n")
WriteStdout(MainType(Child).data.name+" bleh is ")
WriteStdout(MainType(Child).bleh+"~n")

Local Temp:TList = New TList

Temp.AddLast(Main)
Temp.AddLast(Child)

For Local i:MainType = EachIn Temp
	WriteStdout(i.data.name+" bleh is ")
	WriteStdout(i.bleh+"~n")
Next

H&K	(Posted 2007) [#3]

No flame is right, all you are doing is creating a new field with the same short name but different "Stable names"

ie in Child
Self.Bleh and
Super.Bleh
I suppose its usful if you really really really need to "Hide" the high field then use it, but to be honest its just confusing, and I cannot see the point.

Picklesworth

(Posted 2007) [#4]

Ah, that makes sense. Thank you both!

The reason I want this is I need a data object that holds information (arrays / TMaps / etc. would be less fun), and certain objects (extended from the same base object) use certain data objects.

I had it working earlier by having the data field type as just an Object then converting it practically whenever it's mentioned, and it was all quite happy (while my horrible explanation suggests otherwise).
The problem there is that converting the thing constantly is very unpleasant for anyone trying to use the system (especially since it encourages enormous variable names). I'm hoping this will act as a little shortcut...

Picklesworth

(Posted 2007) [#5]

Again, armed with the knowledge I have been newly given by FlameDuck, I guess this makes sense. Kind of surprised me, though.

Strict

Type MainTypeData
	Field name:String="MainType"
End Type

Type ChildTypeData
	Field name:String="ChildType"
	Field iamdifferent:String="I am different!"
End Type

Type MainType
	Field data:MainTypeData=New MainTypeData
	
	Field bleh:Int = 1
	
	Method CreateThis:MainType()
		Return New MainType
	End Method
End Type

Type ChildType Extends MainType
	Field data:ChildTypeData=New ChildTypeData
	
	Field bleh:Float = 7.51
	
	Method CreateThis:ChildType()
		Return New ChildType
	End Method
End Type

Local Main:MainType=New MainType
Local Child:ChildType=New ChildType

WriteStdout(Main.data.name+" bleh is ")
WriteStdout(Main.bleh+"~n")
WriteStdout(Child.data.name+" bleh is ")
WriteStdout(Child.bleh + "~n")

WriteStdout("This is a variable in an object created by the MainType.CreateThis method: " + Main.CreateThis().bleh + "~n")
WriteStdout("This is that variable in an object created by the overrided ChildType.CreateThis method: " + Child.CreateThis().bleh + "~n")

End

Same example, this time overriding method return types.
What I am seeing there is: As long as the overriding method's return type is based on the return type of the method being extended, it can happen. I find it strange that this does not happen with other types that can be converted, like Floats and Ints. (Only with custom types, it appears).

I realize this is really not much over what was already possible, but it saves a lot of typing!
I can't believe I spent a year ignorant of this.

H&K	(Posted 2007) [#6]

Floats and Int arent Objects

You do realise that the old field still exists, and by "Hidding it" you are just wasteing memory?

(Of corse you realise, cos we just told you, but I just wanted to make it clear to everyone else reading)