Menu
▾
▴
Re: [Rails-devel] Emergency train purchases
|
From: Stefan F. <ste...@we...> - 2011-08-01 05:42:19
|
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 |
