The best use or Tlists's
BlitzMax Forums/BlitzMax Beginners Area/The best use or Tlists's
| ||
| I get how to make and use them in general, but was wondering is ther a best way to use Tlists. At the moment i generally make them global eg Global explo:TList=New TList and then access them in the main program is this the preffered method or does it have any benefits all fall downs as compared with say have a Tlist inside the type attached as one of the fields inside the type eg. Type Tstreak Field PointList:TList field all the other fields etc funtions etc methods etc end type i am guessing this way that say if i cal an update(0 from within this type there is no external or main code chunk with the loop going through the list like the first eg where the list is global....... is this a six of one, half dozen of the other is there gunuine benefits from one....any ideas? ta |
| ||
| Having a bit of trouble following your English there, but in general there's no problem having the list as either a global or as a field within a type, or even as a field global. No major benefit either way. It just depends on what is more convenient for the task at hand. |
| ||
| I know it sounds vague, and trite, but put it where it belongs. Either could be right and either could be wrong, you have to do the right thing for the task at hand. Perhaps an example will make my reply less vague and trite. If my Types are Soldier and Orders, let's say we're making a little RTS. Each soldier can have a set of orders given to him by the player and he does them in order. Those orders are his and only his. So of course, they're going to be a field within his object. If there are lots of soldiers, and you need a list of those soldiers then they also relate to soldiers, but they don't relate to just one soldier, they relate to all soldiers, so they should be global within the type. Now perhaps we have a list of messages being displayed on the screen, telling the player what has happened. Those aren't related to the soldier at all, so they go outside the type. Or they may go inside another type, but for simplicity's sake, we'll say they don't. So that gives us : Global DisplayMessages:TList Type Soldier Global List:TList ' List of Soldiers Field Orders:TList ' List of Orders End Type Use the right tool for the right job. The word "has" is usually used as a guiding rule for fields. If you can say "my soldier *has* orders" it should be a field. You can't say "my soldier *has* a list of soldiers" because unless he's the General, he probably doesn't. But it is a list of soldiers, even if each soldier doesn't have one, so it probably should be in there, and those are globals. Related, but not to an instance of the type. And he certainly doesn't have a list of messages being displayed on the screen, and they don't relate to soldiers anyway. So they're not there. |
| ||
| My rule of thumb is "use globals only as a last resort". If it's possible to place the variable within a type as a Field instead, then *generally* that's what you should do. Following that rule can save you big headaches down the track. |
| ||
| Globals within a type are VERY useful and not considered global in the scope of the program. I use globals in the type if the list (or whatever) belongs to the type rather than an instance (e.g. there will only be one list) and as a field when each instance will have it's own list. (as per Gabriel basically). |
| ||
| What exactly does a "global" field inside of a type definition do? The object is accessible from any function anyway, isn't it? Sorry if that's too nooby a question... :) Anyway... thanks to the OP because I didn't know I could/should stuff the list of objects into the object definition itself anyway. Makes for tidier code for me because my lists are all globals and are defined just before the type definition block so I can remember the association. -pmc |
| ||
| Global within a type is : - Available within all functions/methods of the type. - Declared once but keeps it's value. - Is available to all other parts of the program as <type>.name. For example Type TTest global variable Name can be accessed using TTest.Name. |
| ||
| Thats cleared quite a few things up appreciate the help. With blitz3D to get rid of all the types in a list it was a simple as Delete Each MyType is there a quick way to empty all elements out of a Tlist.. |
| ||
| clearlist or method listname.clear |
| ||
| I like extending a type and adding my own fields and methods... |
| ||
| ok just to check i am getting this right, if i declare a global within a type, it is accessible to all methods and functions from within the type, and is accessible from outside by using the typename.variablename convention. A local declared within a type is only used within that method or function and can only be accessed elsewhere only if it is returned as part of a function say. this getting used to oop, is like getting into somebody else's clothes from the wrong end. I guess as long as they look good when on, thats all that matters. The main thing is now i can see how to put them said clothes on the right way....lol. we'll see..... |
| ||
| A local declared within a type is only used within that method or function and can only be accessed elsewhere only if it is returned as part of a function say. As far as I know you can't declare locals in a type, but fields technically are locals, how you're thinking anyways. |
| ||
| locals as in you have to do a for local i =0 to 9 .... next loop sort of thing, or a temp incremental counter of some sort.....within a function or method... |
| ||
Just a for instance... In my football game I have a Type Player. I make a global list in my type and every new player gets added to the list:
Type TPlayer
Global list:Tlist
Field name:String
Function Create(nm:String)
if not list then list = CreateList()
Local newplayer:TPlayer = New TPlayer
newplayer.name = nm
list.AddLast(newplayer)
End Function
Function UpdateAll()
For local player:TPlayer = EachIn TPlayer.list
p.Update()
p.Draw()
Next
End Function
Method Update()
' Run about
End Method
Method Draw()
' DrawImage()
End Method
End Type
Then from your main game loop you can do: TPlayer.UpdateAll() Even better is you can override the compare function to create your own list sorting. So if your type has a field, say "age" you can do TPlayer.list.Sort() to sort them in age order. There was a great tutorial on this kind of stuff but I can't remember which one it was now... Spend an hour reading it though and you'll be set for life. :D |
| ||
| locals as in you have to do a for local i =0 to 9 .... next loop sort of thing, or a temp incremental counter of some sort.....within a function or method... Ah, I misread what you originally said, sorry. |
| ||
| ok just to check i am getting this right, if i declare a global within a type, it is accessible to all methods and functions from within the type, and is accessible from outside by using the typename.variablename convention. A local declared within a type is only used within that method or function and can only be accessed elsewhere only if it is returned as part of a function say. Exactly right. It is all about scope. A global within a type stays in scope even when the function/methods of that type end. This means it can still be accessed. A local defined within a function, method or loop goes out of scope when they finish so is not longer accessible. |
   |