09-08-1999 06:12									#1
	Documentation for the code so far... Support Apolyton, buy Civilization III: Complete

This is automatically generated documentation courtesy of the Javadoc feature of java. If you start at the tree link you'll see all the classes.

I have only so far put descriptions in TF (task force), Unit (military unit), UnitType and UnitStats . For the rest of the files you will get variable and method (routine) names only.

[This message has been edited by Mark_Everson (edited August 11, 1999).]

	02-09-1999 01:45									#2
	Avatar Enlargement: We've got the solution

I just browsed through the four commented classes and wondered about the TF.getTFInfo method: Why did you put five or so "getters" (attack, defence, money, goods, food) into one method? What is the reason that there's not a separate method for each?

Martin
[This message has been edited by mca (edited September 01, 1999).]

	02-09-1999 05:23									#3
	Lose 30 kilos (of popups)

Martin:

I just don't like having zillions of getter and setter methods lying around. It could've gone the other way too. I killed 3 fewer {s and }s doing it my way .

BTW, glad you're interested in helping to code up the map module. It will be so great to have quasi-realistic maps instead of weird stringy ones like in civ2 .

	02-09-1999 14:53									#4
	Avatar Enlargement: We've got the solution

Well, I'll be annoying and ask "why not put all getters into just a few methods, then?" Like this:

float getFloatInfo(int)
int getIntInfo(int)
String getStringInfo(int)

or just one method:

Object getInfo(int) //

If you turn all the int arguments into Strings, scripting languages would also have an easy time.

Martin
[This message has been edited by mca (edited September 02, 1999).]

	02-09-1999 17:16									#5
	Enter the AD-FREE zone

I could have done it like that too. Frankly, I'm a hack-and-slash non-professional programmer, so I don't have 'usual' ways to do a lot of things already figured out. I experimented with different varieties of getters in the new mil code just to see if I liked them. For intra-class information I usually just use the bare variables themselves. So typically I only bother with getters for things when the outside world needs access.

Your point about 'generic' getter methods being good for use with a macro language is interesting. I hadn't gotten that far in my thought processes. (Its first thing in the morning here so I haven't evaluated what you're saying in detail yet ) If you'd like to make other suggestions, I and the rest of the coding group would be glad to hear them. A good suggestion now could save us a lot of work later.

-Mark

	02-09-1999 19:38									#6
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

For usual ways of doing a lot of things already figured out, I have found the book "Design Patterns: Elements of Reusable Object-Oriented Software" by Gamma et al. from Addison-Wesley (ISBN 0-201-63361-2) to be a great source of exactly that. I highly recommend it.

Martin

	02-09-1999 19:45									#7
	Support Apolyton or Terrorists Win

May I disagree?

I believe each 'parameter' (or whatever you like to call variables in a class that can be set/retrieved by the macro code) should have an independent 'get' method and 'set' method.

The 'IO' component should allow for access to each of these by reading the 'macro' code and then calling the required method.

For example, (assuming we were using XML), if you wanted to create a civ you'd write a text file something like:

[Civ]
[Population]100[/Population]
[Location]20, 30[/Location]
[OtherParam]Blah blah[/OtherParam]
[/Civ]

I've substituted '[' in place of '<', since the browser interperets the '<' and '>' as a tag.

The 'IO' component would read this in, parse the tags and route the values accordingly.
[This message has been edited by F_Smith (edited September 02, 1999).]

	02-09-1999 19:55									#8
	Support Apolyton, buy Civilization 2

Re getters and setters:
I must admit that I don't like the idea "generic" getters/setter much, even though I was the one to bring it up. F_Smith makes an excellent suggestion in the "Coding organization for Clash" thread: to use the Bean component model. Also, the Java reflection API can be used by the scripting language to get/set/etc, AFAIK.

Martin

	03-09-1999 09:34									#9
	Avatar Enlargement: We've got the solution

Gentlemen:

Your comments are good ones. I think the main issue is to get us together for an ICQ chat over the weekend and hash this out. I would also like to have JimC there, and of course Blade Runner.

We just need to talk it thru and take note of strengths and weaknesses of each approach. The cases where we don't know the real value / limitations of a particular approach, we'll have to design some simple tests to do soon.

We need to put this decision behind us quickly, or we're going to risk wasting a Lot of coding time.

I will start a new thread on this topic to arrange a time to meet.

Specifically, the notion of using reflection to make generic getters and setters is really attractive to me. Anyone know what the Time penalty is? It could be Very steep.

On XML, does it have loop and branching structures in it? Frankly for simply Setting up parameters for a game I would like to see an off-line editor that scenario designers can use to change all the parameters in the game. I think that would be Much more valuable than XML support.

I really don't know much about beans yet, but am interested in hearing how they could help us.