Conversation with #freelords at Thu 07 Feb 2013 08:30:02 AM CET on ulf82@irc.freenode.net (irc)

(08:30:02 AM) adams.freenode.net: (notice) [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
(08:30:05 AM) ulf82: morning
(08:30:09 AM) Kez_: hi
(08:30:23 AM) ulf82: just one minute to set up everything...
(08:30:31 AM) Kez_: no worries
(08:31:19 AM) ulf82: ok, done.
(08:32:27 AM) ulf82: So, there are principal problems with the blanking, as far as I understand.
(08:32:35 AM) Kez_: yeah
(08:33:48 AM) Kez_: essentially (in the current design) finding a nice way for the super class to return the same class as the caller
(08:33:50 AM) ulf82: Ok, the trivial problem with the Hero.getBackpack() is simple: You just add these functions
(08:34:00 AM) Kez_: and a way to test that the subclass called the super method
(08:34:12 AM) Kez_: yeah cool, that's what I thought
(08:35:42 AM) ulf82: One _could_ use Class.newinstance(), encapsulate this in a BlankingManager, which also cares about exception handling and such.
(08:35:53 AM) ulf82: However, this feels rather complicated.
(08:37:19 AM) ulf82: Alternatively, we could try to use some completely different scheme.
(08:37:24 AM) ulf82: Just need to find something.
(08:37:34 AM) ulf82: brb, making some tea and thinking.
(08:37:40 AM) Kez_: ok
(08:41:27 AM) Kez_: just kind of thinking out loud here: you could separate the blanking into a function that takes an Unit as a parameter, and fill the given unit with the blank data
(08:42:47 AM) Kez_: then for a subclass, say Hero, you can override that function to fill the given Hero with blank data, and pass the Hero down to the super method
(08:43:07 AM) ulf82: another idea would be a more pedestrian approach from scratch.
(08:43:20 AM) ulf82: That we basically skip the blanking and go into more details.
(08:43:49 AM) ulf82: So, the final problem that we want to solve: How do we send a client information about map entities that are not his own?
(08:44:12 AM) ulf82: And there are two kinds of map entities: Buildings and armies.
(08:45:08 AM) ulf82: so if we separate this problem into "telling the client about armies" and "telling the client about buildings", we could solve this in an alternative way.
(08:45:17 AM) ulf82: in a different way
(08:47:33 AM) ulf82: Yet another way would be to separate the blanking into making a copy and blanking
(08:48:35 AM) ulf82: So we require all MapEntities to provide a copy operator.
(08:48:53 AM) ulf82: copy constructor
(08:49:01 AM) Kez_: yeah that seems to be a good solution, as I thin kabout it
(08:49:33 AM) ulf82: The superclass problem should only occur once, in the Hero class.
(08:50:22 AM) Kez_: if you are blanking the object that's running the function, it no longer matters about return types
(08:50:29 AM) ulf82: There you could test explicitely by checking that the Hero has no movement points set.
(08:50:36 AM) ulf82: yes.
(08:51:28 AM) ulf82: Or you take a manager that does the copying.
(08:51:48 AM) Kez_: so are you suggesting that the Hero function and test should just duplicate the Unit ones?
(08:52:00 AM) ulf82: that would be one idea, yes.
(08:52:12 AM) ulf82: There is one principal problem, though:
(08:52:37 AM) ulf82: If you add more functionality to the unit class, it is easy to forget to remove it again in the blank function.
(08:52:45 AM) Kez_: yeah
(08:53:07 AM) ulf82: So maybe the blanking approach is simply bad.
(08:53:23 AM) ulf82: And we should go the other way: Take an empty instance, and _add_ things to it.
(08:53:41 AM) ulf82: If the client is lacking crucial information, you are much more likely to notice.
(08:54:18 AM) ulf82: that turns out trickier than originally thought in any case.
(08:55:26 AM) Kez_: yeah, the adding approach raised these issues, and the copy and remove approach seems like a decent alternative
(08:56:09 AM) ulf82: I would notice two things here:
(08:56:35 AM) ulf82: If we just start with the armies, we have right now, and probably in the nearer future as well, only two types: Heroes and normal units.
(08:57:05 AM) ulf82: So in the agile way, we could restrict our attention only to these objects. For now.
(08:57:20 AM) ulf82: We merely have to make sure that it is not a pain to modify the concept later.
(08:57:42 AM) ulf82: one sec..
(08:59:20 AM) ulf82: sec over.
(09:00:55 AM) ulf82: We could just encapsulate everything in some CopyManager that takes an input army, and provides the same army with minimal information in the output.
(09:01:13 AM) ulf82: That has the advantage that
(09:01:36 AM) ulf82: a) neither Unit nor Army have to care about most of the blanking, which is not their primary concern
(09:01:48 AM) ulf82: b) we have a very simple interface to the outside world.
(09:02:12 AM) Kez_: yeah ok
(09:02:19 AM) ulf82: so if we need to extend later, this can be all hidden behind this interface.
(09:03:01 AM) ulf82: I just deleted task 185, along the way.
(09:03:09 AM) Kez_: cool
(09:03:42 AM) ulf82: and, just to wrap it up, c) the interface provides what we are interested in: blanking the army, not single units.
(09:03:52 AM) ulf82: Ok.
(09:04:14 AM) ulf82: Then let's try to shape this idea a bit:
(09:04:21 AM) ulf82: 1. How do we call the class and the method?
(09:04:33 AM) Kez_: Specific to Armies?
(09:04:40 AM) ulf82: yes
(09:04:45 AM) ulf82: well, the class.
(09:04:54 AM) ulf82: The method I would recycle for the buildings
(09:06:30 AM) Kez_: ArmyCopyManager? although Copy is not quite what we're doing
(09:08:36 AM) ulf82: yes.
(09:09:21 AM) ulf82: but I do not have a really better idea, either.
(09:09:37 AM) ulf82: so maybe we can take this for now. Renaming is cheap.
(09:09:44 AM) Kez_: true
(09:10:16 AM) ulf82: for the function, we could have getBlankCopy()
(09:10:37 AM) Kez_: seems reasonable
(09:11:06 AM) ulf82: ok.
(09:11:14 AM) ulf82: Now let's try to specify the behaviour.
(09:11:35 AM) ulf82: What should the function do (also in terms of testing the function)?
(09:11:41 AM) ulf82: your turn. :)
(09:12:04 AM) Kez_: well, it wants to return a blank version of the army
(09:12:22 AM) ulf82: which it gets as parameter. yes.
(09:12:25 AM) Kez_: which means it wants to return an Army full of blank versions of the other's Units
(09:12:38 AM) ulf82: how does a blank version look like?
(09:12:57 AM) Kez_: at this point the same as the original, but with movement points removed
(09:13:33 AM) ulf82: or in better terms: it only contains the base stats
(09:13:37 AM) Kez_: yeah
(09:13:43 AM) ulf82: (to use the adding instead of removing language)
(09:13:58 AM) ulf82: what if the unit is a hero?
(09:14:11 AM) Kez_: but I'm unsure as to how this class will be able to create a new Unit and fill it with the appropriate values
(09:15:02 AM) Kez_: hero has all items removed
(09:15:10 AM) ulf82: I just notice that there is a much simpler way....
(09:15:26 AM) ulf82: You could use the UnitManager and just create a completely new unit from scratch
(09:16:49 AM) ulf82: That requires that the type of a unit is somehow valid (there is a unit definition file for every unit in the game), but this could be required by convention.
(09:17:46 AM) ulf82: just as an idea, one step back:
(09:17:56 AM) ulf82: The unit manager already creates fresh new units for us.
(09:17:59 AM) ulf82: UnitManager
(09:18:03 AM) Kez_: yep
(09:19:05 AM) ulf82: So, using this, together with the existing unit's type, would do most of the backend work.
(09:19:31 AM) ulf82: to answer your question from above. :)
(09:19:39 AM) Kez_: yeah
(09:19:53 AM) ulf82: regarding the hero: since the name might be relevant, I would suggest, a Hero needs to have the name added as well.
(09:20:12 AM) ulf82: (the original name)
(09:20:18 AM) Kez_: but could still be loaded from a definition file?
(09:20:37 AM) ulf82: yes.
(09:20:51 AM) ulf82: we will have to require then that each unit has a type definition.
(09:21:03 AM) ulf82: including heros.
(09:21:07 AM) Kez_: yeah ok
(09:21:26 AM) ulf82: Ok.
(09:21:39 AM) ulf82: Let me try to summarize, you interrupt when you see unclear points:
(09:21:48 AM) ulf82: 1. We add an ArmyCopyManager
(09:22:05 AM) ulf82: 2. This has a function getBlankCopy()
(09:22:22 AM) ulf82: - it gets an army as input, and creates a blanked army as output.
(09:22:27 AM) ulf82: - specifically:
(09:22:38 AM) ulf82: - if you have a unit, it creates the unit afresh
(09:22:56 AM) ulf82: - if you have a hero in the army, it in addition sets the hero's name to the original
(09:23:35 AM) ulf82: Do you see any more things to do?
(09:23:53 AM) Kez_: where does the ArmyCopyManager get it's UnitManager from?
(09:24:11 AM) ulf82: ah, yes. This needs to be injected in the constructor
(09:24:42 AM) Kez_: ok
(09:25:08 AM) ulf82: and is of course required then, otherwise you get an exception etc.
(09:25:14 AM) Kez_: yep
(09:25:27 AM) ulf82: ok, then let us write up this task.
(09:25:30 AM) ulf82: do you want?
(09:26:05 AM) Kez_: oh, also, where in Unit is the unitDefinition? / untType?
(09:26:12 AM) ulf82: yes
(09:26:22 AM) Kez_: there is a 'type' there already
(09:26:44 AM) ulf82: Well, yes. It never had a function up to now. :)
(09:27:06 AM) ulf82: (well, you could already use it in the UnitManager, but it was never used in-game)
(09:27:10 AM) ulf82: brb
(09:27:15 AM) Kez_: cool
(09:31:53 AM) ulf82: back
(09:32:17 AM) ulf82: along the way, come to think of it, the UnitManager also allows you fine-grained control in the tests.
(09:32:25 AM) ulf82: you could just mock it.
(09:32:49 AM) Kez_: that works quite well then
(09:33:01 AM) Kez_: added the task, if you'd like to take a look
(09:33:17 AM) ulf82: and if the mocked manager returns mocked units, you can even make sure that the code does nothing except for what you want it to.
(09:33:56 AM) ulf82: one thing: It should not copy a unit, but a whole army
(09:34:05 AM) Kez_: ah yes, woops
(09:34:16 AM) ulf82: just correcting...
(09:34:54 AM) ulf82: done
(09:35:02 AM) Kez_: cool
(09:35:06 AM) ulf82: Ok, then I would suggest that this is your next week's work.
(09:35:13 AM) Kez_: ype
(09:35:20 AM) ulf82: Then next time we can discuss:
(09:35:31 AM) ulf82: - how to deal with buildings in a similar way
(09:36:00 AM) ulf82: - just as a thought: Whether we want to use the same scheme also for the map and player blanking.
(09:36:20 AM) ulf82: (to keep the code more boring in a positive way)
(09:37:05 AM) Kez_: yeah that's probably a good idea
(09:37:24 AM) ulf82: Ok. Then I think that would be it for today.
(09:38:25 AM) ulf82: Do you have courses right now, by the way, or are there breaks?
(09:38:46 AM) Kez_: I'm still on break, for one more week
(09:38:55 AM) ulf82: ok.
(09:39:11 AM) ulf82: then relax well. :)
(09:39:25 AM) Kez_: cheers :) I'll see you later then
(09:39:29 AM) ulf82: cu