When to Extend?
BlitzMax Forums/BlitzMax Beginners Area/When to Extend?
| ||
| I have a baseunit type with common fields x,y etc. There are 2 kinds of units which use exactly the same fields but will be use slightly different functions/methods and be in seperate lists. Is it better to use extend for these units or to use a single type function with an 'If unittype=1' clause? This might be obvious as I continue but I don't want to go down the wrong path early on. |
| ||
| Extend is the easier way as you can extend the program with further unit types later without any problems. just define all needed functions in the basetype as abstract. |
| ||
| Hi, My personal opinion is to use extends as seldom as possible - save it for when it actually gives you some functional advantage. Just because 2 objects have an x,y field does not necessarily mean they should share a common base type. That said, if you're having to use a 'select/case' inside a method, this may be a sign that you should indeed be extending. |
| ||
| Another time you may want to extends, is if you need to make a more advanced version of one of the blitzmax types. For example I have extended the TList object, to TListEx .. which has some more functions that my program needed. |
| ||
| Hard to say without knowing exactly what you are coding for. I find a good way to figure how to define your types is to describe how they link to each other. for example I define a type called engine that defines details for a petrol engine. Now I want to define a car. Do I extend the engine to make a car which has wheels ect ?.. or do I create a new type of car that contains an engine ?.. well.. in this case is is fairly simple.. a car contains an engine but does a whole lot of other stuff. If I then want a diesal engine.. well.. i would extend the engine because it does the same thing but with a different power source. I want a truck ?.. well.. it does pretty much all the things a car does... it is just a variation of a car. A speedboat ?.. OK.. that uses an engine but doesnt really have many features a car has so in this case it is a new type which contains an engine. Does that make sense ? |
| ||
| Is it better to use extend for these units or to use a single type function with an 'If unittype=1' clause? It depends, but generally it is better to use extends and let the compiler worry about which unittype you've got.However if they are in seperate lists, (and thus being traversed seperately) I'm not entirely sure what the problem is exactly. |
| ||
| Thanks for the responses so far. For a bit more explanation. I have a type called shadow_makers. This type has, for example, X,Y,Image and (will have) a list of points which make a convex hull. There will be 2 types of shadow_makers: Blockers and Casters. Blockers will block light while Casters will block light AND cast a shadow. They both belong to a main list of 'game objects' and seperate lists of casters and blockers. If I create 2 'extends' type then the only difference is the method(s) to cast a shadow. On the other hand I can have the single type and simply use either the lists or a simple field (set to 'caster' or 'blocker') to determine those objects which need a shadow. Hope that makes sense. P.S. You might have guessed I'm trying to write a light/shadow system. ;) Getting 'stuck' this early doesn't bode well. |
| ||
| Another approach that sounds good for your application is to have just one type with one or more fields that control the behaviour. Thus Casters and Blockers could be collapsed into say Shape which has CastsLight and BlocksLight flags. If the attributes and behaviours of Casters and Blockers are so similar then I would recommend this approach. It is a bit like your 'if unittype=1' approach but it makes the reasons for the different behaviour clearer. Every method/function where the light interaction is not important does not have to worry about the difference. Alternative is to have Shape as the base and then extend it for both Caster and Blocker. BTW commonly recommended naming standard is not to use the plural form in naming objects. So Caster rather than Casters. The issue of lists is a good example of where BlitzMax opens up whole new possibilities. You can for example maintain three lists in the type. Always add a new object to the main list but then add it to CasterList or BlockerList depending upon the attribute when it is created. This works well unless there needs to be a lot of list maintenance such as deleting objects and switching them between Caster and Blocker lists. Which is best ? Look at the alternatives, even rough out the code for each and see which is more flexible and results in the least/clearest/cleanest code. Efficiency will probably no be much differnt and is really not that important in almost all situations unless you do something crazy. Let us know how it turns out. |
| ||
| Hi PGF, Your first approach is exactly what I've got at the moment. It seems in situations where there isn't a wide difference in the 'types' that extending or 'IFing' is personal preference. I'll keep going (slowly). Cheers |
   |