Thread: [Rails-devel] PlayerManager rewrite for 1880

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Martin & Alexander & Erik:
I did a complete rewrite of the PlayerManager to include 1880 
requirements that allows a change of player order.

One issue I have to solve is the following:
In some cases of Rails players are identified by index and not by name. 
However index is both a property of the Player (thus static) and 
PlayerManager (thus for 1880 dynamic).

I propose to use the player Names as identifiers for players instead of 
the index. Actually they are used as the official id inside the Rails 
players objects in 2.0 already.

May intention is to drop index altogether and rely only on name.

I have still to identify which old existing code refers to what (player 
order or player index identity) and then replace that accordingly.

All methods in PlayerManager that deal with the index are set to 
deprecated to indicate that. However they will be removed at the end of 
this process.

Fortunately the PossibleAction class already writes both index and name 
to the save files, so we should be able to keep the existing save files 
without conversion and writing support code for this.

Erik: Do you have any other idea or comment, what we should consider here?

Please review my changes in rails_2_develop_1880. The code compiles, 
however does not run so far, until the index issue is solved.

Stefan

Some further details on the rewrite:

This is a good example how I best-practice structure of elements in 1880 
looks like:

* If several states belong to a common structure create a Model (here 
PlayerOrderModel) and have all of them contained inside.

This is the only place where I use some "magic", which I usually do not 
like, as it might surprise some. Models get automatically subscribed as 
models to states where they are parents to.

So you do need to add the Model to the state using state.addModel(model).
Usually it is the case for states that are defined as fields inside of 
models and you avoid to have state.addModel(this) for all states.

Using this mechanism the model is always updated if any of the contained 
states are updated and all observers of the model get updated as well. 
However you are free to bind the Model to any other state (or other model).

And yes: I use a topological sort to figure out which model has to be 
updated if the model graph gets more complex. It detects and reports 
cycles to the log-file ;-) Currently the structure of Rails models is 
not that complex...

* If the model is closely tied to a Rails class make the Model a static 
nested class of the Rails class.

This strongly shows that this model should only be created from inside 
that class. If the constructor is made private, that will be the case.

* Put most of the controlling and interacting code with the outside 
world inside the (main) Rail class. The model should mainly used to 
store the states and allow interaction with the states. And it is the 
outside than shown to the UI client.

This is still be done here.

* And there are a lot of nice features in the Google Guava library to 
write concise and fluent code. Take a look if you think you are missing 
some nice feature from more modern languages.

Thread: [Rails-devel] PlayerManager rewrite for 1880

rails-devel