put the list in the type
BlitzMax Forums/BlitzMax Beginners Area/put the list in the type
| ||
Im trying to put the list in the actual type like this:Type warrior extends character Global list:TList function create() If list=Null list:TList = CreateList() EndIf end function end type but it always says the object is null when I try to use the list |
| ||
Use:Field list:TList [edit]Based on the bit of code you posted above you might as well just do this: Field list:TList = New TList |
| ||
| thanks, If I put it in a field then every type instance will have its own list. on the asteroids in an hour tutorial they make it a global to stop this. |
| ||
| Well whether your list is global or a field depends what it's a list of. If you're trying to emulate B3D's list of all objects of that type then having it global is the correct way. From the question, I'm not entirely sure which it is you're after. I'm also not sure if you're expecting Create to be called automatically, but just to point out that it won't be. The only thing which is called automatically is the New() method. So either put it there or have it automatically create upon initialization of the type, eg: Global List:TList=New TList Or if you want a list in each object, as in GFK's reply Field List:TList=New TList |
| ||
| thanks, how would I access the list (global) when I want to iterate through it with the eachin command (in the main program outside of the type) |
| ||
| Through the 'namespace' ie warrior.list |
| ||
Well personally I wouldn't access it from outside the type. I'd write whatever code needed to handle the list inside the type. But if it's global you just address it as Warrior.List Although it can actually be addressed via an instance of the warrior type too. Eg: MyWarrior:Warrior=New Warrior MyWarrior.List But the former is more correct. |
| ||
| You wouldn't do that. Breaks any clean OO design rule. If you have a functionality that needs to iterate through that list, implement it within the type and call that function that iterates through it and does a special thing. Examples for that are Update, Draw, CheckCollision |
| ||
| Like what Dreamora says :-) The reason being, that because the nitty-gritty code is hidden away inside the Type, you can, at a later date, completely re-write that part of it without having to change code outside of the Type. Otherwise, can you imagine the chaos of having to change, say, 7 areas of your program, because your List is now implemented in a different way? You want to make your life as easy as possible, after all :-) |
| ||
| got it working now, thanks all, I will put all iterations in the type |
| ||
| Shouldn't you have the list in the character type, to store all your characters including warriors in one place rather than a seperate list for each type of character? A character list could store anything that inherits from character. |
| ||
| Shouldn't you have the list in the character type, to store all your characters including warriors in one place rather than a seperate list for each type of character? You should probably have both. You'll normally have operations you want to carry out on all characters, but at the same time, you might well have operations you only want to carry out on warriors. While you can iterate through a list of all characters, it's inevitably slower to say For Local W:Warrior=EachIn Character.List Next Than it is to say For Local W:Warrior=EachIn Warrior.List Next Object Oriented Programming can be very useful for games, but for me it's much more of a double-edged sword than it is for application programming. Application programming rarely has to worry about milliseconds. A good solid algorithm more than makes up for a few milliseconds here and there because of OOP. With games, it's a constant battle between doing things the best way and doing things the fastest way. If you potentially have a lot of characters and need to process something on warriors every frame, you have to decide if you can afford to lose those precious CPU cycles iterating through a list with many objects you don't want. |
| ||
| the only problem is that you have to remove the instance from all lists, maybe that isnt too much to remember for most people. |
| ||
| If these are player charectors which won't change in number too oftend, I'd consider an array. |
| ||
| the only problem is that you have to remove the instance from all lists, maybe that isnt too much to remember for most people. easy... from your extended type's custom Remove method call the base type's Remove method. each method cleans up it's own list by deleting the link in it's own list directly. |
| ||
| Tut tut dmaz http://englishplus.com/grammar/00000227.htm |
   |