Re: [Rails-devel] Emergency train purchases

[Erik V. <eri...@xs...>]

> > What kind of new classes would we need then?  These would need access
> > to many of the internals of Round and its subclasses, but I think
> > these can't themselves be (Operating)Round subclasses.n A new
> > hierarchy starting with an abstract top class named Step?
> 
> I simply asked to put the new code into a new class EmergencyTrainBuying
> and putting all code related to that there. I did not ask for a fully
refactoring
> of OperatingRound. All required information could have been passed per
> argument to them (and if they need full access then pass a reference to
the
> OperatingRound itself). This would have been easy.

I'm sorry to have disappointed you...

It is a misunderstanding that Rails has such a process called "emergency
train buying" that is separate from normal train buying, or that it could be
relevant to create such a distinction. 
(It's not even clear to me what "emergency" exactly means. I'm taking it to
mean that the president must add cash. It is not a very useful concept in
Rails. I'm mainly alluding to it because many game rule sets do.)

setBuyableTrains() sorts out all train buying possibilities, emergency or
not, and presents these as one list  of train buying options to the user. 
Only after the user has made a choice we know if the "emergency" qualifier
applies.  The only exception is if the company has zero cash: then we know
beforehand.
But even with $1 it's (almost) always (if only theoretically) possible to
buy a train from another company, and then there is no "emergency" in the
sense I understand this word.
 
As I have said before, all I have done is updating and somewhat
restructuring the existing method setSuyableTrains(), and make it use the
new configuration settings. The only real new code is parsing these new
settings (in GameManager).
In theory I could have moved this setSuyableTrains() method to somewhere
else, but I don't know a better place.  

Defining and applying a new concept of classes that perform certain OR steps
(e.g. TrainBuying) would be a much bigger step than what I have done now. 
I'm open to discuss that. But I don't see any benefit in haphazardly putting
random bits of code into new classes because some class has grown a bit
large.
(And IMO both would increase rather than decrease complexity.)

> Nearly all changes to adapt other 18xx games to Rails evolve around this
class
> and if it is so difficult and dangerous to change this class, this itself
is a strong
> case to actually make it simpler and less dangerous.

I don't consider OperatingRound to be "dangerous" at all - why would it be?
The various actions are well separated and identifiable. The complexities
are inside the methods, not in the number of it, or in their relationships
(as far as I'm aware).

Would it help to give this class some more structure by sorting the methods
into sections with a descriptive header, like "Main process", "Tile laying",
"Revenue and Dividend" etc.?

Erik.