From: Stefan F. <ste...@we...> - 2012-09-03 20:30:58
|
I try to collect several replies on Money and Bank issues to John's and Erik's comments. On 09/03/2012 12:18 AM, Erik Vos wrote: > > Money is not an item but an amount, I'd say. Nothing moves, just equal > amounts get added and subtracted. To me, it's fundamentally different from > all other Rails objects, and should be treated in its own way. > For me an Integer amount can move as well (and in Java Integers can be first-class citizens as well). But I prefer the term to "wire" the Integer money amount ;-) However Money gets a different treatment to Trains, as it is not "Ownable" but "Countable" and stored in a "Wallet" and not a "Portfolio". Further all classes that get own money get an additional Interface "MoneyOwner" and this takes Money above the level of a Train as there is no such thing as a "TrainOwner". > On 2012-09-02 15:18, Erik Vos wrote: >> Your way, nothing should happen if a wallet gets a negative amount. You can >> no longer do this check at the lowest level, because the bank only breaks >> if the total amount of all its wallets becomes negative, not if any one of >> these does. So that kind of check must always be done at a higher (the >> owner's) level, as a separate action after each move at a lower level. Not >> sure how you are going to manage that. > The check for the bank broken will be inside a Model (BankWalletModel) that contains the BankWallet(s) as member(s). On 09/03/2012 03:27 AM, John David Galt wrote: > I've been assuming that if you attempt a money move that would make a Wallet > negative, it would throw an exception; but the bank's Wallet would be a > special case, and would allow the move but set a BankHasBroken flag. Wallets currently does not check for negative amounts. I am considering adding the option to a Wallet to only allow positive values, but that is not the case now. *** Some further thoughts on my proposal with the separate Wallets for IPO and Pool in addition to a Bank wallet. You should not judge the proposal so much on its implementation, but on its outcome: If done correctly ... * To transfer money to the Bank you can use either Bank or IPO or Pool as the counterparty. This especially allows a symmetric behavior that if you buy e.g. a Train from the IPO you can pay to the IPO. Otherwise you would always have to remember that you buy from IPO, but pay to Bank (thus the parent of IPO). If you buy a train from another company, you will pay the other company and not the parent of that company. * If you ask Bank or IPO or Pool for getCash() you will get the total amount of money in the bank as the answer. * The check for bank broken will always work on the correct total amount of the bank money. So for the main use cases it behaves like one wallet, it is only the internal wiring which uses three wallets. The only disadvantage is the use case of a correction mechanisms as suggested in a previous mail. Here would have to aggregate the three wallets manually again. *** 1825 (et.al) company credits: On 09/02/2012 08:21 PM, John David Galt wrote: > The point is that company credits, when they exist, are not supposed to count > toward breaking the bank. Thus if you change a game that uses credits by > giving the companies ordinary cash, then when determining whether the bank has > broken you have to count as if all the cash in company treasuries were still > in the bank. That was my intention for a simple implementation. > > Actually I don't recommend combining the types of money this way because it > creates another inaccuracy. The smallest company credit "bill" is £10, so all > company treasuries are supposed to be constrained to multiples of 10. Actually I have not considered that as a game mechanic, but simply a matter of no-need for smaller bills: I had the impression that there is no allowed transaction for companies that requires smaller amounts, but if there are cases we have to consider that rule: What actually happens in those cases (overpayment, rounding)? Stefan |