Troubles with types

BlitzMax Forums/BlitzMax Beginners Area/Troubles with types

Drekinn

(Posted 2005) [#1]

Just a few uncertainties about types:

1) What happens if you create new instances of a type but don't add them to a list? Will they be inaccessible?

2) When attempting to access the field value of a derived type why is the base type field value returned? (Accessing the derived type's methods and functions work as expected). For example:

SuperStrict

Type animal
	Field name:String = "Animal"
	
	Method eat()
		Print name + " eating food"
	End Method
End Type

Type cat Extends animal
	Field name:String = "Cat"
	
	Method eat()
		Print name + " eating fish"
	End Method
End Type

Print
Local pet1:animal = New animal
Print pet1.name
pet1.eat

Print
Local pet2:animal = New cat
Print pet2.name  'Why is this not printed as "Cat" ?
pet2.eat

Print
Local pet3:cat = New cat
Print pet3.name
pet3.eat

3) What are the benefits of declaring a new instance of a type using both the base and derived type names? Example:

pet1:animal = New cat

as opposed to just declaring:

pet1:cat = New cat

Any enlightenment would be appreciated,

PowerPC603

(Posted 2005) [#2]

1) If you would use:

Local pet:Animal = New Animal
Local pet:Animal = New Animal

Then the address of the first animal is overwritten by the address of the second animal.
That leaves the first animal instance unreferenced (no variable points to it anymore) and will be deleted by the next FlushMem.

2) I'm not sure about this, but I think you are actually declaring a new Animal object, which is extended by the Cat object's fields.
I think that's why the Name-field from the Animal type is returned.
Personally I think that you should never have 2 fields with the same name, that's just asking for confusion.

3) The benefit is that you can use that same variable with several different types:

pet:Animal = New Animal
pet:Animal = New Cat
pet:Animal = New Dog
pet:Animal = New Fish

You can also check if an object is of a certain type:

If Dog(pet) then Print "This object is of type Dog"
If Cat(pet) then Print "This object is a fish"

The casting ("Dog(pet)" for example) returns the address of the object if the pet is actually a dog and returns "0" if the pet-variable points to another type (a fish for example).
So the If statement is True (any other value than "0") if the pet-variable holds a pointer to a Dog-object.

Also you can use that same approach for passing any animal to a function:

Function ProcessAnimal(pet:Animal)
	Select True
		Case Dog(pet)
			...
		Case Fish(pet)
			...
		Case Cat(pet)
			...
		Case Animal(pet)
			...
	End Select

	...
End Function

Now you can pass any type of animal (an animal object or any of the derived types of an animal), check to see which kind it really is (by casting) and processing it, using a select case statement for example and just doing what needs to be done per type of animal.

Drekinn

(Posted 2005) [#3]

PowerPC603,

1) Aha, understood.

2) Yes, you're right. I shouldn't need to specify the same field for derived types. Silly me.

3) Excellent. This answer has addressed a lot of misconceptions I had with using types in this way. Yippee! :)

Thank you so much,

Who was John Galt?

(Posted 2005) [#4]

@Drekinn

You probably figured this already, but it makes no odds if you declared a new cat as of type cat or animal - so

pet:cat=new cat
processanimal (pet)

will work too.

Drekinn

(Posted 2005) [#5]

Nomen luni,

Thanks for the tip. :)