TList - Best Practice

Hi All,

In my games I normally have different lists for different types.

For example in my latest game I have got a type of building and a type of person with lists of buildings and people:

Type TBuildings Extends TList

Type TBuilding Extends TSprite

Type TPeople Extends TList

Type TPerson Extends TSprite

Now what I want to know is: Is this the best way?

I know you can one list which contains different types: Is this better?

Cheers

Probably, unless you have resources that will be retrieved and manipulated a lot there really isn't a need to use TMaps.

I would assume not.. In the background it still has to go over the objects that aren't what your enumerating for.

yes, as Plash mentioned, and why would you go through a bunch of object that have nothing to do with objects that you need?

I don't understand why you are extending TList. What more are you adding?

Thanks for the replies... Ill guess Ill keep doing the same way then ;-)



Stuff like:
* AddNew
* Draw
* Manage
* Kill

For example:

Type TBuildings Extends TList
	Method AddNew:TBuilding(x:Int, y:Int, image:TGameImage)
		Local s:TBuilding = TBuilding.Create(image, x, y)
		s.buildings = Self 'point to this list		
		AddLast(s)
		Return s
	End Method

	Method Draw()
		Local s:TBuilding
		For s = EachIn Self
			s.Draw()			
		Next
	End Method	
	
	Method Manage()
		Local b:TBuilding

		For b = EachIn Self
			b.Manage()
		Next
		
	End Method
	
	Method Kill()		
		For Local s:TBuilding = EachIn Self
			s.Kill()
		Next
	End Method
	
End Type

Yes, but why extend TList. Just have a TList in your type.

Hmmmm

Something like this?:

Type TBuilding Extends TSprite
	Global list:TList
	
	Function createBuilding(x%,y%,gi:TGameImage)
		local b:TBuilding = new TBuilding
		If list = Null list = CreateList()
		list.addlast(b)
	End Function
	
	Function manageAll()
		for local b:TBuilding = eachin list
			b.manage()
		next
	End Function
	
	Function drawAll()
		for local b:TBuilding = eachin list
			b.draw()
		next
	End Function
		
	Method manage()
		' manage stuff
	End Method

	Method draw()
		' draw stuff
	End Method
End Type

Is this better than what I had before?

Either way does the same thing, but the latter way is what would come more naturally to me.

Either way it doesn't really matter, but with the list-in-your-type format you can have your very own type hierarchy.

Aggregation, is generally considered better than inheritance for OO programming.

Think of it as a more modular/encapsulated way of doing things, if you add a list to your objects then you can more easily change it to an array or Map if needed without effecting code that calls your objects!

hmm. I learned some things from this thread. But why is the list (in the last example) a global? Is it just so that the functions within the type have access to it?

-pmc

Yes, it is just so that the functions/everything within the type has access to it.

But will the global list be global to the entire application, not just the type?

Yes, but encapsulated in the type. So to access the global list from outside the type you need to use:
TBuilding.list

BTW when you access objects in the list you need to ensure that the list is not null, for example

if not list return

At the top of the functions...

	Function drawAll()
		if not list return

		for local b:TBuilding = eachin list
			b.draw()
		next
	End Function

BTW Thanks guys for the replies to my original question, coding this way is a lot neater and self contained :)