Re: [Rails-devel] Current implementation, branch Rails 2.0?

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

See below.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]

> In my understanding of Rails the term action is something different: All
of
> them are user's actions and extend  the abstract class PossibleAction and
> belong to the rails.game.action package.
> 
> This new kind of "action" is in my eyes a named trigger which is activated
by
> the train purchase. 

By the phase change, to be precise.  Indeed the term "action" is a bit
confusing.

> There is no need to pass the trigger through
> GameManager and Round classes with new methods and then call from the
> OperatingRound the method inside PublicCompany_TN.
> 
> My preferred solution would have been the possibility for
> PublicCompany_TN to register themselves with the PhaseManager and then
> get updated directly.

That's indeed another possible approach.  I'll consider it.
It's probably more fashionable. 

> And only by convention actions are passed from GameManager to the Round
> (sub-)classes , but they design neither encourages nor enforces this:
> Take for example the correction actions, they are processed in individual
> manager classes, and there is one for each action. 

I'm not sure if that doesn't amount to multiplying entities beyond
necessity.

> If I have taken your
> approach all code inside the correction package would have been added to
> the GameManager too.
> And that is my proposal or roadmap for those classes: Try to get
> GameManager focused on what is required for the top level class of the
> game (thus mainly storing the other component managers and interacting
> between them). Clean up the Rounds to include only the mechanisms to
> proceed from activity/step to the next and to switch between
> players/companies. All action processing should be done outside in
individual
> components/classes.
> 
> For you it might seem easier to have everything in one place/file, but  I
would
> prefer to refactor it somehow, before I am able to implement required
> adjustments for other games.
> 
> Similar as it is difficult for you to write revenue code, it is difficult
for others to
> change the Round or GameManager classes. But if nearly everything
> important is inside those classes, no one else will be able to help you
> implement the parts of new games that require changing those classes.
> 
> But if you split those classes into smaller pieces it makes it easier for
> outsiders (including myself) to understand the insides and it is less
risky to
> change it without causing side effects.

As I proposed before, I can reorganize OperatingRound to group the methods
by function (OR step), each with some descriptive header.
That's all I can do on short term. It might make OR easier to read, and
perhaps it could be a starter for later refactoring.

> See below for some stats if you do not believe my words.

All fine, but so what?  Is size bad per se?  

> However as I seem it hardly possible to refactor against a moving target
(as
> you are stilling adding new functions to the core classes - and rightly do
so, as
> long as there is no alternative), I suggest to create a new branch inside
the git
> repo for a potential Rails 2.0.

Large-scale refactoring of Rails should certainly be done in a separate
branch.

Erik.