rails-devel

Re: [Rails-devel] Emergency train purchases

[Stefan F. <ste...@we...>]

Erik,
I understand that in your definition of the scope of the Operating Round class, emergency train buying belongs there. Thus I should better ask for a narrower scope of this class. Including everything what is required for processing actions from companies operating is in my opinion too broad. But I know your different opinion. However this scares other purple from changing anything there. I would only dare to change the class after serious refactoring. I hope you do not mind my different view.
Stefan


Erik Vos <eri...@xs...> schrieb:

>Stefan,
>
>All I'm doing now is updating the existing OperatingRound setBuyableTrains()
>method, using a few generic configuration settings, to implement the
>possible answers to a single main question that arises if a company has no
>trains:  
>
>	Which trains are allowed to be bought at which (maximum) price,
>given the amount of cash *currently* owned by the company and its president?
>
>So far the following decision factors that affect the answer to this main
>question have been identified:
>1. If a train from the Bank is bought, must the company buy the cheapest
>(used) train, even if he has sufficient cash to buy a more expensive (new)
>train?
>2. If not, may the president add cash to buy a new train if the company only
>has sufficient cash to buy a cheaper used train? 
>3. May presidents add cash to buy a train from a company?
>4. If so, to what maximum price? (Usually list price is the upper limit, but
>the allowed max. price can be lower if the president is not allowed to sell
>shares in this case, which always seems to be so. In that case the max.
>price is the lowest of the list price and the total cash owned by the
>company and its president.  So I think this question is practically
>equivalent to: May a president raise cash, e.g. by selling shares, to help
>buying a train from a company?  So far the answer to that last question
>always seems to be "no", which would make this question redundant).
>
>I appreciate all efforts to explain to me how companies and presidents can
>raise cash by other means, such as selling shares, taking loans, issuing
>bonds etc., but that is *not* what I'm currently asking for.  As it turns
>out, getting the answers to the above questions is difficult enough, and
>that is all I need in this stage.
>
>What I might do for you is to abstract away these decisions in Boolean
>methods (still in OperatingRound) that can be overridden. But I'm not sure
>to what extent that would be helpful. I don't expect many game-specific
>variations on the number of these basic decisions (affecting that single
>main question) and their possible answers.
>
>Please note, that I intend to put the new configuration settings under
><GameParameters> in Game.xml.  For instance, for 1856 I now have
>	<OperatingRound
>class="rails.game.specific._1856.OperatingRound_1856">
>	                <EmergencyTrainBuying mustBuyCheapestTrain="yes"
>mayBuyFromCompany="no"/>
>	</OperatingRound>
>These new game parameters will be stored in the common gameParameters
>collection in GameManager; the grouping under <OperatingRound> is only
>logical, not physical.
>
>Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Tuesday, July 26, 2011 12:12 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Emergency train purchases
>> 
>> Erik:
>> I cannot add now to any of the rules question as I am currently traveling,
>but
>> it seems that you are considering already a broad variety of rules.
>> 
>> I only ask for a favor with respect to the implementation:
>> Could you please put (nearly) all code related to the emergency train
>> purchases into one (new) class: Most likely a sub-component of
>> TrainManager.
>> This would also allow it to be easily be replaced by games which have
>not-yet
>> considered rules.
>> Please avoid adding it to the OperatingRound class as I intend it to
>refactor it
>> anyhow into smaller pieces.
>> 
>> Thanks,
>> Stefan
>> 
>> 
>>
>----------------------------------------------------------------------------
>--
>> Magic Quadrant for Content-Aware Data Loss Prevention Research study
>> explores the data loss prevention market. Includes in-depth analysis on
>the
>> changes within the DLP market, and the criteria used to evaluate the
>> strengths and weaknesses of these DLP solutions.
>> http://www.accelacomm.com/jaw/sfnl/114/51385063/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>------------------------------------------------------------------------------
>Magic Quadrant for Content-Aware Data Loss Prevention
>Research study explores the data loss prevention market. Includes in-depth
>analysis on the changes within the DLP market, and the criteria used to
>evaluate the strengths and weaknesses of these DLP solutions.
>http://www.accelacomm.com/jaw/sfnl/114/51385063/
>_______________________________________________
>Rails-devel mailing list
>Rai...@li...
>https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Emergency train purchases

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

Stefan,

Well, I am not against restructuring per se, but I wouldn't know how to do
that, and I certainly don't consider it a high priority.

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.
A new hierarchy starting with an abstract top class named Step? 

In any case, it'll be a lot of work, and I would be concerned about all
currently unforeseeable side effects that breaking up OperatingRound might
have.  

Didn't you have some plan to accomplish this?

Anyway, by now I have so many other items on my to-do list that I'm not
really eager to pick up this one.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Wednesday, July 27, 2011 7:13 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Emergency train purchases
> 
> Erik,
> I understand that in your definition of the scope of the Operating Round
> class, emergency train buying belongs there. Thus I should better ask for
a
> narrower scope of this class. Including everything what is required for
> processing actions from companies operating is in my opinion too broad.
But I
> know your different opinion. However this scares other purple from
> changing anything there. I would only dare to change the class after
serious
> refactoring. I hope you do not mind my different view.
> Stefan
> 
> 
> Erik Vos <eri...@xs...> schrieb:
> 
> >Stefan,
> >
> >All I'm doing now is updating the existing OperatingRound
> >setBuyableTrains() method, using a few generic configuration settings,
> >to implement the possible answers to a single main question that arises
> >if a company has no
> >trains:
> >
> >	Which trains are allowed to be bought at which (maximum) price,
> given
> >the amount of cash *currently* owned by the company and its president?
> >
> >So far the following decision factors that affect the answer to this
> >main question have been identified:
> >1. If a train from the Bank is bought, must the company buy the
> >cheapest
> >(used) train, even if he has sufficient cash to buy a more expensive
> >(new) train?
> >2. If not, may the president add cash to buy a new train if the company
> >only has sufficient cash to buy a cheaper used train?
> >3. May presidents add cash to buy a train from a company?
> >4. If so, to what maximum price? (Usually list price is the upper
> >limit, but the allowed max. price can be lower if the president is not
> >allowed to sell shares in this case, which always seems to be so. In that
case
> the max.
> >price is the lowest of the list price and the total cash owned by the
> >company and its president.  So I think this question is practically
> >equivalent to: May a president raise cash, e.g. by selling shares, to
> >help buying a train from a company?  So far the answer to that last
> >question always seems to be "no", which would make this question
> redundant).
> >
> >I appreciate all efforts to explain to me how companies and presidents
> >can raise cash by other means, such as selling shares, taking loans,
> >issuing bonds etc., but that is *not* what I'm currently asking for.
> >As it turns out, getting the answers to the above questions is
> >difficult enough, and that is all I need in this stage.
> >
> >What I might do for you is to abstract away these decisions in Boolean
> >methods (still in OperatingRound) that can be overridden. But I'm not
> >sure to what extent that would be helpful. I don't expect many
> >game-specific variations on the number of these basic decisions
> >(affecting that single main question) and their possible answers.
> >
> >Please note, that I intend to put the new configuration settings under
> ><GameParameters> in Game.xml.  For instance, for 1856 I now have
> >	<OperatingRound
> >class="rails.game.specific._1856.OperatingRound_1856">
> >	                <EmergencyTrainBuying mustBuyCheapestTrain="yes"
> >mayBuyFromCompany="no"/>
> >	</OperatingRound>
> >These new game parameters will be stored in the common
> gameParameters
> >collection in GameManager; the grouping under <OperatingRound> is only
> >logical, not physical.
> >
> >Erik.
> >
> >> -----Original Message-----
> >> From: Stefan Frey [mailto:ste...@we...]
> >> Sent: Tuesday, July 26, 2011 12:12 PM
> >> To: Development list for Rails: an 18xx game
> >> Subject: Re: [Rails-devel] Emergency train purchases
> >>
> >> Erik:
> >> I cannot add now to any of the rules question as I am currently
> >> traveling,
> >but
> >> it seems that you are considering already a broad variety of rules.
> >>
> >> I only ask for a favor with respect to the implementation:
> >> Could you please put (nearly) all code related to the emergency train
> >> purchases into one (new) class: Most likely a sub-component of
> >> TrainManager.
> >> This would also allow it to be easily be replaced by games which have
> >not-yet
> >> considered rules.
> >> Please avoid adding it to the OperatingRound class as I intend it to
> >refactor it
> >> anyhow into smaller pieces.
> >>
> >> Thanks,
> >> Stefan
> >>
> >>
> >>
> >-----------------------------------------------------------------------
> >-----
> >--
> >> Magic Quadrant for Content-Aware Data Loss Prevention Research study
> >> explores the data loss prevention market. Includes in-depth analysis
> >> on
> >the
> >> changes within the DLP market, and the criteria used to evaluate the
> >> strengths and weaknesses of these DLP solutions.
> >> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> >-----------------------------------------------------------------------
> >------- Magic Quadrant for Content-Aware Data Loss Prevention Research
> >study explores the data loss prevention market. Includes in-depth
> >analysis on the changes within the DLP market, and the criteria used to
> >evaluate the strengths and weaknesses of these DLP solutions.
> >http://www.accelacomm.com/jaw/sfnl/114/51385063/
> >_______________________________________________
> >Rails-devel mailing list
> >Rai...@li...
> >https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Emergency train purchases

[Stefan F. <ste...@we...>]

Erik:
thanks for your response. I am little disappointed that you were not able to 
do me that favor, as this implies that it makes my planned changes more 
difficult. Usually I try to follow requests from Brett and you even in those 
cases where I cannot understand the reasons for them ;-)
Most likely it was a misunderstanding.
Stefan

More detailed comments see below.


On Wednesday, July 27, 2011 11:35:54 pm Erik Vos wrote:
> Stefan,
> 
> Well, I am not against restructuring per se, but I wouldn't know how to do
> that, and I certainly don't consider it a high priority.

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

> 
> In any case, it'll be a lot of work, and I would be concerned about all
> currently unforeseeable side effects that breaking up OperatingRound might
> have.

Full refactoring is a lot of work I agree and the fact the author of the class 
himself is concerned about unforeseeable side effects is a strong argument 
that refactoring of a class is a high priority.

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.

> 
> Didn't you have some plan to accomplish this?

Yes I have, but every addition of further functionality and dependency to this 
class makes this plan harder and harder.

> 
> Anyway, by now I have so many other items on my to-do list that I'm not
> really eager to pick up this one.

I am not eager to do this either, but someone has to swallow the bitter pill.
All I am asking is not make the taste even more bitter.

> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Wednesday, July 27, 2011 7:13 AM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Emergency train purchases
> > 
> > Erik,
> > I understand that in your definition of the scope of the Operating Round
> > class, emergency train buying belongs there. Thus I should better ask for
> 
> a
> 
> > narrower scope of this class. Including everything what is required for
> > processing actions from companies operating is in my opinion too broad.
> 
> But I
> 
> > know your different opinion. However this scares other purple from
> > changing anything there. I would only dare to change the class after
> 
> serious
> 
> > refactoring. I hope you do not mind my different view.
> > Stefan
> > 
> > Erik Vos <eri...@xs...> schrieb:
> > >Stefan,
> > >
> > >All I'm doing now is updating the existing OperatingRound
> > >setBuyableTrains() method, using a few generic configuration settings,
> > >to implement the possible answers to a single main question that arises
> > >if a company has no
> > >
> > >trains:
> > >	Which trains are allowed to be bought at which (maximum) price,
> > 
> > given
> > 
> > >the amount of cash *currently* owned by the company and its president?
> > >
> > >So far the following decision factors that affect the answer to this
> > >main question have been identified:
> > >1. If a train from the Bank is bought, must the company buy the
> > >cheapest
> > >(used) train, even if he has sufficient cash to buy a more expensive
> > >(new) train?
> > >2. If not, may the president add cash to buy a new train if the company
> > >only has sufficient cash to buy a cheaper used train?
> > >3. May presidents add cash to buy a train from a company?
> > >4. If so, to what maximum price? (Usually list price is the upper
> > >limit, but the allowed max. price can be lower if the president is not
> > >allowed to sell shares in this case, which always seems to be so. In
> > >that
> 
> case
> 
> > the max.
> > 
> > >price is the lowest of the list price and the total cash owned by the
> > >company and its president.  So I think this question is practically
> > >equivalent to: May a president raise cash, e.g. by selling shares, to
> > >help buying a train from a company?  So far the answer to that last
> > >question always seems to be "no", which would make this question
> > 
> > redundant).
> > 
> > >I appreciate all efforts to explain to me how companies and presidents
> > >can raise cash by other means, such as selling shares, taking loans,
> > >issuing bonds etc., but that is *not* what I'm currently asking for.
> > >As it turns out, getting the answers to the above questions is
> > >difficult enough, and that is all I need in this stage.
> > >
> > >What I might do for you is to abstract away these decisions in Boolean
> > >methods (still in OperatingRound) that can be overridden. But I'm not
> > >sure to what extent that would be helpful. I don't expect many
> > >game-specific variations on the number of these basic decisions
> > >(affecting that single main question) and their possible answers.
> > >
> > >Please note, that I intend to put the new configuration settings under
> > ><GameParameters> in Game.xml.  For instance, for 1856 I now have
> > >
> > >	<OperatingRound
> > >
> > >class="rails.game.specific._1856.OperatingRound_1856">
> > >
> > >	                <EmergencyTrainBuying mustBuyCheapestTrain="yes"
> > >
> > >mayBuyFromCompany="no"/>
> > >
> > >	</OperatingRound>
> > >
> > >These new game parameters will be stored in the common
> > 
> > gameParameters
> > 
> > >collection in GameManager; the grouping under <OperatingRound> is only
> > >logical, not physical.
> > >
> > >Erik.
> > >
> > >> -----Original Message-----
> > >> From: Stefan Frey [mailto:ste...@we...]
> > >> Sent: Tuesday, July 26, 2011 12:12 PM
> > >> To: Development list for Rails: an 18xx game
> > >> Subject: Re: [Rails-devel] Emergency train purchases
> > >> 
> > >> Erik:
> > >> I cannot add now to any of the rules question as I am currently
> > >> traveling,
> > >
> > >but
> > >
> > >> it seems that you are considering already a broad variety of rules.
> > >> 
> > >> I only ask for a favor with respect to the implementation:
> > >> Could you please put (nearly) all code related to the emergency train
> > >> purchases into one (new) class: Most likely a sub-component of
> > >> TrainManager.
> > >> This would also allow it to be easily be replaced by games which have
> > >
> > >not-yet
> > >
> > >> considered rules.
> > >> Please avoid adding it to the OperatingRound class as I intend it to
> > >
> > >refactor it
> > >
> > >> anyhow into smaller pieces.
> > >> 
> > >> Thanks,
> > >> Stefan
> > >
> > >-----------------------------------------------------------------------
> > >-----
> > >--
> > >
> > >> Magic Quadrant for Content-Aware Data Loss Prevention Research study
> > >> explores the data loss prevention market. Includes in-depth analysis
> > >> on
> > >
> > >the
> > >
> > >> changes within the DLP market, and the criteria used to evaluate the
> > >> strengths and weaknesses of these DLP solutions.
> > >> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> > >> _______________________________________________
> > >> Rails-devel mailing list
> > >> Rai...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > >
> > >-----------------------------------------------------------------------
> > >------- Magic Quadrant for Content-Aware Data Loss Prevention Research
> > >study explores the data loss prevention market. Includes in-depth
> > >analysis on the changes within the DLP market, and the criteria used to
> > >evaluate the strengths and weaknesses of these DLP solutions.
> > >http://www.accelacomm.com/jaw/sfnl/114/51385063/
> > >_______________________________________________
> > >Rails-devel mailing list
> > >Rai...@li...
> > >https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> - --
> 
> > Got Input?   Slashdot Needs You.
> > Take our quick survey online.  Come on, we don't ask for help often.
> > Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> > http://p.sf.net/sfu/slashdot-survey
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

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.