Documentation for the code so far...

[Mark_Everson]

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).]

[mca]

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).]

[Mark_Everson]

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 .

[mca]

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).]

[Mark_Everson]

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

[mca]

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

[F_Smith]

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).]

[mca]

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

[Mark_Everson]

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.