rails-devel — List for discussion of Rails development

[Rails-devel] Rails 2.0: Next Status Update

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

** Another milestone is reached:
Two of the test games in 1889 (1889_A and 1889_B in test/real) can be 
replayed in full and the complete UI comes up without error. Still a few 
rough edges, but all actions get processed.

In addition there are few tests that are missing in Rails 1.x. All tests 
throw a RuntimeError exception, thus currently Rails2.0 fails fast.

* If the ChangeStack is closed, no state can be changed.

* Loaded actions are validated using .equalsAsOption against the 
available actions.

* No item/component with an identical id can be created during the game 
(exception due to undo).

I will do an alpha release for others to test soon (maybe in one week or 
so), but please do not expect anything exciting (the next milestone is 
to reach the compatibility with and the stability of Rails1.x).

** Next steps:
The immediate next step is to merge/adopt all changes of Rails1.x after 
were added after Rails2.0 branched off.

Completing that I will release beta versions.

Then I will focus on refactoring the round classes and finalizing 1825.

Finishing 1825 will be the trigger to release Rails 2.0.

** Rails 1.x
If one considers to add new feature or games, my recommendation is now 
to make those changes for Rails2.0. I understand if others (especially 
Erik) is reluctant to change already, but I cannot guarantee that I will 
adopt changes which will be committed to Rails 1.x
However I will do releases for Rails1.x if there is the need to do so.

Re: [Rails-devel] HomeCityNumber (city attribute)

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

Oh, and to answer your question: it is quite possible that stops.get()
should have been mStops.get(), but I'm not entirely sure.
The question is: why do we have both stops and mStops? Probably there is
some reason, but I must (again) dig deep into this stuff to give the final
answer.

Erik.

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Wednesday, September 05, 2012 3:31 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: RE: [Rails-devel] HomeCityNumber (city attribute)
> 
> Hi Stefan,
> 
> The HexMap stop (city) number is a separate entity from the tile city
> number.
> Initially, it is derived from the city numbers of the first tile laid, or
the
> preprinted tile if it already has tracks.
> When tiles are upgraded, the HexMap city numbers normally do not change;
> the HexMap stops become related to the new tile cities, in a way that
> existing tracks remain connected to a HexMap stop with the same number.
> This means, that after an upgrade the HexMap city numbers may become
> different from the current tile city numbers. The current tile city
numbers
> have no meaning for game play.
> 
> If the old tile had no tracks, there is nothing to preserve, so the new
tile city
> numbers are just copied. Any home token stops on such tiles have city
> number 0, which indicates that these must be assigned manually as soon as
a
> tile with some track is laid (Erie, THB, Badische).
> 
> If during an upgrade the number of stops on a tile changes, HexMap stop
> numbers are reassigned, although (I believe) it is attempted to retain the
old
> numbers where possible.
> 
> This all is complex stuff indeed. It took me a lot of time and false
starts to get
> this reasonably working, and it is quite possible that cases exist that do
not
> work out well.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Wednesday, September 05, 2012 1:57 PM
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] HomeCityNumber (city attribute)
> >
> > Erik,
> > is it intentional that the HomeCityNumber refers to the position
> > inside the list of Stops of HexMap?
> >
> > I refer to the following code in method layHome of mapHex:
> >
> >                  Stop homeCity = stops.get(Math.max(stopNumber - 1, 0));
> >                  homes.put(company, homeCity);
> >
> > I thought that mStops.get(...) instead of stops.get(...) would have
> > been the more logical choice as mStops maps the stations/stops ids to
the
> objects.
> >
> > Usually if Rails refer to Stations it is the number defined by
> > position on the tile and not the order number.
> >
> > This caught me by surprise yesterday and took quite some time to track
> > down.
> >
> > This has a strong influence on the definition of the city attribute of
> > the Home
> > tag: Instead of the specification of the station position, it refers
> > to the ordering of stations inside the Tile definition.
> > However in the full loop it makes some sense, as in the Tile
> > definition the stations have ids, that are identical with the ordering
of the
> definitions.
> >
> > But those ids are not used to set up the station numbers, those are
> > based on the position on the tile.
> >
> > As you are the expert of Tile and Map definitions, I want to ask you
> > for your
> > opinion: Is there more behind it or is it something we should fix in
> > the longer run at least (and could add some comments in the
> > code/configuration for this behavior)?
> >
> > Stefan
> >
> > ----------------------------------------------------------------------
> > --------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
latest in
> malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] HomeCityNumber (city attribute)

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

Hi Stefan,

The HexMap stop (city) number is a separate entity from the tile city
number. 
Initially, it is derived from the city numbers of the first tile laid, or
the preprinted tile if it already has tracks.
When tiles are upgraded, the HexMap city numbers normally do not change; the
HexMap stops become related to the new tile cities, in a way that existing
tracks remain connected to a HexMap stop with the same number.
This means, that after an upgrade the HexMap city numbers may become
different from the current tile city numbers. The current tile city numbers
have no meaning for game play.

If the old tile had no tracks, there is nothing to preserve, so the new tile
city numbers are just copied. Any home token stops on such tiles have city
number 0, which indicates that these must be assigned manually as soon as a
tile with some track is laid (Erie, THB, Badische).

If during an upgrade the number of stops on a tile changes, HexMap stop
numbers are reassigned, although (I believe) it is attempted to retain the
old numbers where possible.

This all is complex stuff indeed. It took me a lot of time and false starts
to get this reasonably working, and it is quite possible that cases exist
that do not work out well.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Wednesday, September 05, 2012 1:57 PM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] HomeCityNumber (city attribute)
> 
> Erik,
> is it intentional that the HomeCityNumber refers to the position inside
the list
> of Stops of HexMap?
> 
> I refer to the following code in method layHome of mapHex:
> 
>                  Stop homeCity = stops.get(Math.max(stopNumber - 1, 0));
>                  homes.put(company, homeCity);
> 
> I thought that mStops.get(...) instead of stops.get(...) would have been
the
> more logical choice as mStops maps the stations/stops ids to the objects.
> 
> Usually if Rails refer to Stations it is the number defined by position on
the
> tile and not the order number.
> 
> This caught me by surprise yesterday and took quite some time to track
> down.
> 
> This has a strong influence on the definition of the city attribute of the
Home
> tag: Instead of the specification of the station position, it refers to
the
> ordering of stations inside the Tile definition.
> However in the full loop it makes some sense, as in the Tile definition
the
> stations have ids, that are identical with the ordering of the
definitions.
> 
> But those ids are not used to set up the station numbers, those are based
on
> the position on the tile.
> 
> As you are the expert of Tile and Map definitions, I want to ask you for
your
> opinion: Is there more behind it or is it something we should fix in the
longer
> run at least (and could add some comments in the code/configuration for
this
> behavior)?
> 
> Stefan
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] HomeCityNumber (city attribute)

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

Erik,
is it intentional that the HomeCityNumber refers to the position inside 
the list of Stops of HexMap?

I refer to the following code in method layHome of mapHex:

                 Stop homeCity = stops.get(Math.max(stopNumber - 1, 0));
                 homes.put(company, homeCity);

I thought that mStops.get(...) instead of stops.get(...) would have been 
the more logical choice as mStops maps the stations/stops ids to the 
objects.

Usually if Rails refer to Stations it is the number defined by position 
on the tile and not the order number.

This caught me by surprise yesterday and took quite some time to track down.

This has a strong influence on the definition of the city attribute of 
the Home tag: Instead of the specification of the station position, it 
refers to the ordering of stations inside the Tile definition.
However in the full loop it makes some sense, as in the Tile definition 
the stations have ids, that are identical with the ordering of the 
definitions.

But those ids are not used to set up the station numbers, those are 
based on the position on the tile.

As you are the expert of Tile and Map definitions, I want to ask you for 
your opinion: Is there more behind it or is it something we should fix 
in the longer run at least (and could add some comments in the 
code/configuration for this behavior)?

Stefan

Re: [Rails-devel] Rails2.0: Money and Bank (was: Rails2.0: Further Changes)

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

> You should not judge the proposal so much on its implementation, but on
> its outcome: If done correctly ...

Its implementation bears upon efficiency, and IMO that what is at stake
here.
 
> This especially allows a symmetric behavior that if you buy e.g. a Train
> from the IPO you can pay to the IPO. 

Yes. I do not put that into question.

> So for the main use cases it behaves like one wallet, it is only the
> internal wiring which uses three wallets.

Accepting all your previous reasoning, I still don't see why  the IPO and
Pool wallets cannot be (or point to) the same object as the Bank's wallet.
The split still seems completely unnecessary to me.
If it is an inevitable consequence of your architecture, then too bad for
that architecture.

But let's stop arguing. 

Erik.

[Rails-devel] Rails2.0: Money and Bank (was: Rails2.0: Further Changes)

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

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

Re: [Rails-devel] Rails2.0: Portfolios, Ownable and Owner

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

Erik,
answers see below:

On 09/03/2012 05:01 PM, Erik Vos wrote:
> Stefan,
>
> I do not want to have a big argument over these matters, that's not worth
> it, but I'm trying to understand the reasoning behind your 'natural order',
> and I cannot find it.
>
>> You can call this reverted, but your proposal is symmetric:
>> Take the indexInCompany as the default Comparator and create the Player
>> portfolios with the a Comparator based on the order of president and
>> certificate type.
>>
>> As soon as you want support two (or more) different sortings you need one
>> (or more) "non-natural" Comparator(s).
>
> But what is then the use case of your 'natural order'?

Sorry mentioned it at the beginning of the discussion, but maybe did not 
stress enough, that it is an arbitrary choice.

It is the one used for display in the UI: For certificates it is the 
(default) sorting for the detailed certificate list in the UI.

So the "advantage" of a sorted set (collection) is that you do not have 
to sort again anytime you update the UI.

The wording "natural order" only refers to the fact that I define it as 
the order for the Comparable interface: So any sort without an explicit 
Comparator given will use that order.

>
> Let's look at the most obvious use cases:
>
> 1. Initial purchase from IPO. Fixed order, as configured. This usage calls
> for a List.

I totally agree that the IPO is sorted differently than other Portfolio 
(both for display and usage). But you won't disagree, that the IPO is 
sorted.

>
> 2. Purchase from Pool or Treasury. In most cases, just one share can be
> bought, so all you need is a single (any) share per share size. Any ordering
> can handle this, though a Map per share type (size) would help, or a Set per
> share type. Is that what you do? Current code just iterates over all shares,
> and any iterable collection type can handle this equally well, though a List
> looks most efficient. Order doesn't matter at all.

Certificates are stored in a PortfolioMap, however the keys are 
PublicCompanies and not CertificateTypes.
Main reason is that Portfolio only allows one Portfolio per Type and 
PortfolioMap only allows one level of typing (we would need a Map of Map).
So it would be possible to create a Portfolio that separates by
CertificateTypes, but then we would have to filter by company.

>
> 3. Finding which and how many shares can be sold. Here you need counts of
> each share type (size). Basically what I said for use case 2 applies here
> too.
>
> 4. Add up share worth. Again, any iterable collection can handle this.
>
> Nowhere I can find any reason to have such a thing as your 'natural order'.
> So I'm curious what use case you think would benefit from such an order.  I
> must be missing some point...
> (Of course it's possible that you have explained it in the past perfectly
> well, and then I apologize for having forgotten it).
>

Again: You are right those use cases give no reason for different 
orderings, except for the fact that I believe the ordering of the IPO 
and the ordering to display the shares in the UI can be different.

Could it be that you do not mind the ordering as such, but that you 
still dislike the choice of a set instead of a list?
And you are right that if coded correctly a list works as well as a 
(sorted)set and is more efficient, but I prefer the built-in protection 
of the set against coding errors that create undo problems that are 
difficult to track.

Stefan

[Rails-devel] Rails2.0: Layers / Packages (was: Rails2.0: Further Changes)

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

Erik:
actually I do not think I have changed the layer/package structure 
substantially. To the contrary I tried to keep most of the terminology 
and structure of Rails1.x.

I mostly agree with your characterization, however I do not agree that
the game components classes and the round classes are in different 
layers. I think that the game logic is shared between the two in the 
current implementation and it is the correct way to do so.
Or better: That there is no correct way to create a strict separation 
such that the game logic is only kept in one or the other.

So my current understand about the Rails structure:

1. There is a core engine layer in rails.game.state, which provides

A) The Change/State mechanics
B) The Item hierachy
C) Portfolio and Wallets are a hybrid of both A) and B)

This layer does not assume anything about 18xx games at all and could be 
used to support any other (board)game computer implementation.

2. The main 18xx classes in rails.game, which provides

A) The game components like Bank, Companies, Certificates etc.
B) The game mechanics like Rounds
C) Managers are a hybrid to link and support A) and B)

This layer should support all standard elements of 18xx games, but no 
special stuff. I intend to split that into sub-packages as rails.game 
really grew very large. I was considering something like 
rails.game.components and rails.game.rounds

3. The main classes use components from the following packages

A) rails.game.action for game actions
B) rails.game.model for components that can be observed by the UI
C) rails.game.special for special properties

I believe that the separation between 2. and 3. is not a very strong 
one, as there is a strong interdependence between elements both in 2. and 3.

E.g. it would make sense to put the related models and the game 
components into one package.

4. Then there are two service packages

A) The rails.algorithm package for network calculations
B) The rails.correction package for correction mechanisms

5. And two utility packages

C) The rails.common package for xml parsing and other supporting services
D) The rails.util package for further utilities, which do not find 
anywhere else

6. UI packages in rails.game.ui.*

7. Game specific packages in rails.game.specific.*

The dependency structure is:

The game engine (2/3) depends on the core(1) and utility(5)
The service classes (4) depend on the game engine(2/3)
The UI(6) depends on the game engine (2/3) and the service classes (4)

Game specific classes either change the game engine(2/3), service 
classes(4) or the UI(6).


>
> Now we have (at least) three layers (in my view). The terminology is mine
> (and I have used a similar concept successfully several times throughout my
> career in IT):
>
> 1. The application layer. In Rails, that's mostly the Round classes.
>
> 2. The service layer. Companies, Portfolios and such. I think the Managers
> belong here too.
>
> 3. The lowest layer (core). That is (in Rails) where you register States,
> move items around, manage Undo stacks etc.
>
> In my opinion, your "little bit more complexity" should be handled in the
> service layer.  If that is what you intend to do, I'm happy.
> But if you put it in the application layer, then I start worrying.
>
> Erik.
>

Re: [Rails-devel] Rails2.0: Further Changes

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

> It often might seem simpler to drop some restrictions of the core engine
and
> add the special rules inside the core engine. However this makes the core
> engine less robust and might fail at some other places.
> So I usually prefer to allow a little bit more complexity at the outer
layers if I
> can keep the core simple and unchanged.

Of course, you want to have the layer where Undo/Redo are executed as simple
as possible. That's the lowest layer, I understand.

Another consideration is that the services offered to the application layer
should be as simple as possible, in the sense that the application
programmer should not have to worry about technical details. Such as how
wallets are constructed. 

Now we have (at least) three layers (in my view). The terminology is mine
(and I have used a similar concept successfully several times throughout my
career in IT):

1. The application layer. In Rails, that's mostly the Round classes.

2. The service layer. Companies, Portfolios and such. I think the Managers
belong here too.

3. The lowest layer (core). That is (in Rails) where you register States,
move items around, manage Undo stacks etc.

In my opinion, your "little bit more complexity" should be handled in the
service layer.  If that is what you intend to do, I'm happy. 
But if you put it in the application layer, then I start worrying.

Erik.

Re: [Rails-devel] Rails2.0: Portfolios, Ownable and Owner

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

Stefan,

I do not want to have a big argument over these matters, that's not worth
it, but I'm trying to understand the reasoning behind your 'natural order',
and I cannot find it.

> You can call this reverted, but your proposal is symmetric:
> Take the indexInCompany as the default Comparator and create the Player
> portfolios with the a Comparator based on the order of president and
> certificate type.
> 
> As soon as you want support two (or more) different sortings you need one
> (or more) "non-natural" Comparator(s).

But what is then the use case of your 'natural order'? 

Let's look at the most obvious use cases:

1. Initial purchase from IPO. Fixed order, as configured. This usage calls
for a List.

2. Purchase from Pool or Treasury. In most cases, just one share can be
bought, so all you need is a single (any) share per share size. Any ordering
can handle this, though a Map per share type (size) would help, or a Set per
share type. Is that what you do? Current code just iterates over all shares,
and any iterable collection type can handle this equally well, though a List
looks most efficient. Order doesn't matter at all.

3. Finding which and how many shares can be sold. Here you need counts of
each share type (size). Basically what I said for use case 2 applies here
too.

4. Add up share worth. Again, any iterable collection can handle this.

Nowhere I can find any reason to have such a thing as your 'natural order'.
So I'm curious what use case you think would benefit from such an order.  I
must be missing some point...
(Of course it's possible that you have explained it in the past perfectly
well, and then I apologize for having forgotten it).

Erik.

Re: [Rails-devel] Rails2.0: Further Changes

[John D. G. <jd...@di...>]

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.

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.

Re: [Rails-devel] Rails2.0: Further Changes

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

> However there is at least one use case with a disadvantage:
> A general correction mechanism, which shows all portfolios containing one
> type of items and allow moving back and forward between them. For this
> use case a n:1 relationship complicates things a bit, but it is not
impossible to
> solve the issues.

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.

> The code would be different however:
> bankWallet = Wallet.create(bank, "wallet", Currency.class)
> bankWallet.addOtherOwner(bank.getIpo());
> bankWallet.addOtherOwner(bank.getPool());

Indeed.

> I am undecided, as it is possible to achieve the same result with a
slightly
> more complicated solution for the (special) Bank case.

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.

To prevent such complications, I'd rather have a little bit more complexity
at a lower level (if needed at all, but I don't think so).

Erik.

Re: [Rails-devel] Rails2.0: Portfolios, Ownable and Owner

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

The Comparator would be based on the already available indexInCompany 
variable in Rails1.x (which is identical to the id in Rails2.0).

So you provide create a Comparator and pass that to the constructor of 
the IPO portfolio.

So the IPO portfolio will be sorted by the purchase order, whereas the 
Player portfolios will be sorted by president and certificate type 
(which I call the natural ordering).

You can call this reverted, but your proposal is symmetric:
Take the indexInCompany as the default Comparator and create the Player 
portfolios with the a Comparator based on the order of president and 
certificate type.

As soon as you want support two (or more) different sortings you need 
one (or more) "non-natural" Comparator(s).

I have the strong doubt that I will not convince you, and most likely 
your reasons against using a Set are as good and valid as mine for not 
using a List (mainly to avoid undo and testing related problems).

However I do not see that much difference between a list with an 
implicit ordering (initial IPO sequence) of unique elements and a 
SortedSet, except that you have to ensure the correct order by the code 
using the portfolio. For the sorted set you have to write code to 
specify the order, but after that the portfolio guarantees the ordering.

Stefan


On 09/02/2012 10:52 PM, Erik Vos wrote:
> I would say: the natural ordering is the order in which shares are initially
> sold.
> I would strongly advise against meddling with that order.
> For that reason, I'm not at all convinced that a Set is better than an Array
> to hold the company certificates.
>
> Having to create a special Comparator to restore the initial order (how to
> configure that?) sounds like doing it backwards to me (we Dutch call that
> "putting the horses behind the carriage").
>
> In special cases like the Prussian, or the SJ in 18Scan, where non-president
> shares can be bought before the company floats, there is no reaI need to
> have the President certificate on top, although I would still consider that
> 'natural'. These cases need special code anyway.
>
> Also keep in mind conversions from 5-share into 10-share companies, and
> other variations on that theme.
>
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Sunday, September 02, 2012 4:04 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Rails2.0: Portfolios, Ownable and Owner
>>
>> Erik:
>> the underlying TreeSet allows to optionally specify a Comparator which
>> deviates from the natural ordering.
>>
>> Thus it is easy to add a different ordering to the IPO portfolio.
>>
>> But thanks for reminding me of that, do you know other cases where the
>> ordering of a "portfolio" in Rails 1.x is important for game mechanics?
>>
>> Stefan
>>
>> On 09/02/2012 12:41 PM, Erik Vos wrote:
>>> Stefan,
>>>
>>>> * PublicCertificates are sorted by
>>>> i) President or not
>>>> ii) CertificateType (and those are sorted by number of shares inside)
>>>> iii) CertificateId
>>>>
>>>> This keeps the PresidentShare at position zero of each portfolio
>>>> without requiring any code to keep it there. And it keeps the
>>>> multi-shares at the
>>> top
>>>> of a list of certificates.
>>>
>>> How will you then handle the 1835 double shares that must appear at
>>> the
>>> *bottom* of the IPO stack (BA, WT and HE)?
>>> Currently, specification order determines IPO order.
>>>
>>> Erik.
>>>
>>>
>>> ----------------------------------------------------------------------
>>> --------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond.
>>> Discussions will include endpoint security, mobile security and the
>>> latest in malware threats.
>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and threat
>> landscape has changed and how IT managers can respond. Discussions will
>> include endpoint security, mobile security and the latest in malware
> threats.
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails2.0: Further Changes

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

General remark first:
To understand my approach it is important that I try to construct robust 
and simple core elements, which do not take into account all special 
rules, but provide a few hooks to allow the creation of special rules 
without changing the core mechanisms.

It often might seem simpler to drop some restrictions of the core engine 
and add the special rules inside the core engine. However this makes the 
core engine less robust and might fail at some other places.
So I usually prefer to allow a little bit more complexity at the outer 
layers if I can keep the core simple and unchanged.

Specific remark here:
In the current definition there is a one-to-one relationship between
(owner,type) <-> portfolio<type> and wallet<type>

Buy your question below is a good one: Would it be possible to for a n:1 
relationship? For the core mechanism it is possible, as currently we 
only ask for the wallet/portfolio given the owner and type.

However there is at least one use case with a disadvantage:
A general correction mechanism, which shows all portfolios containing 
one type of items and allow moving back and forward between them. For 
this use case a n:1 relationship complicates things a bit, but it is not 
impossible to solve the issues.

The code would be different however:
bankWallet = Wallet.create(bank, "wallet", Currency.class)
bankWallet.addOtherOwner(bank.getIpo());
bankWallet.addOtherOwner(bank.getPool());

I am undecided, as it is possible to achieve the same result with a 
slightly more complicated solution for the (special) Bank case.

Stefan


On 09/02/2012 11:19 PM, Erik Vos wrote:
> Then I don't see why this WalletManager could not, when asked for the IPO
> wallet, return the Bank wallet.
> Perhaps it's just me, but I don't see any benefit, just problems, with
> splitting up the Bank cash this way.
>
> public BankMoneyModel(Bank bank) {
> 	bankWallet = Wallet.create(bank, "wallet", Currency.class);
> 	ipoWallet = bankWallet; // redundant code, of course, but I hope you
> get the point.
> 	poolWallet = bankWallet;
> 	bankWallet.addModel(this);
> }
>
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Sunday, September 02, 2012 11:06 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Rails2.0: Further Changes
>>
>> It might sound more complicated, but it is a consequence of the indirect
>> access to Wallets and Portfolios.
>>
>> The link between the Wallet and the Owner is defined once and forever by
>> creating a Wallet with the Owner as the parent.
>>
>> It does not matter where the Wallet lives (e.g. inside a variable of the
> owner
>> itself, inside a PortfolioModel or stored at a completely different
> object).
>>
>> At the time of adding money the Owner is NOT asked for its wallet, but the
>> wallet for the according owner is provided by the WalletManager by asking
>> for the correct Wallet for the (Owner, Type) combination.
>>
>> A potential code snippet for an aggregate BankMoneyModel class:
>>
>> private Wallet<Currency> bankWallet;
>> private Wallet<Currency> ipoWallet;
>> private Wallet<Currency> poolWallet;
>>
>> public BankMoneyModel(Bank bank) {
>> 	bankWallet = Wallet.create(bank, "wallet", Currency.class);
>> 	ipoWallet = Wallet.create(bank.getIpo(), "wallet", Currency.class);
>> 	poolWallet = Wallet.create(bank.getPool(), "wallet",
> Currency.class);
>> 	bankWallet.addModel(this);
>> 	ipoWallet.addModel(this);
>> 	poolWallet.addModel(this);
>> }
>>
>> public int getCash() {
>> 	return bankWallet.value() + ipoWallet.value() + poolWallet.value();
> }
>>
>> In the example above you could wire money to Bank, Pool or Ipo and it has
>> the same net effect to the BankMoneyModel.
>>
>> The MoneyOwner interface is only a helper/legacy interface to allow an
> easy
>> access the cash value.
>>
>> On 09/02/2012 10:30 PM, Erik Vos wrote:
>>>> However it might make the code easier to assume that IPO/Pool etc.
>>>> have their own cash wallet to make the item buying code easier:
>>>> Then the counterparty of the item transaction is identical to the
>>> counterparty
>>>> of the accompanying cash transaction.
>>>
>>> To me, that sounds like making life more complicated rather than
>>> making it simpler.
>>> Why then not have the Bank portfolios contain a reference to the Bank
>>> Wallet?
>>> Or indeed, include into every Portfolio a reference to its owner's
> Wallet.
>>>
>>> Erik.
>>>
>>>
>>> ----------------------------------------------------------------------
>>> --------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond.
>>> Discussions will include endpoint security, mobile security and the
>>> latest in malware threats.
>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and threat
>> landscape has changed and how IT managers can respond. Discussions will
>> include endpoint security, mobile security and the latest in malware
> threats.
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails2.0: Further Changes

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

Then I don't see why this WalletManager could not, when asked for the IPO
wallet, return the Bank wallet.
Perhaps it's just me, but I don't see any benefit, just problems, with
splitting up the Bank cash this way.

public BankMoneyModel(Bank bank) {
	bankWallet = Wallet.create(bank, "wallet", Currency.class);
	ipoWallet = bankWallet; // redundant code, of course, but I hope you
get the point.
	poolWallet = bankWallet;
	bankWallet.addModel(this);
}

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday, September 02, 2012 11:06 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Rails2.0: Further Changes
> 
> It might sound more complicated, but it is a consequence of the indirect
> access to Wallets and Portfolios.
> 
> The link between the Wallet and the Owner is defined once and forever by
> creating a Wallet with the Owner as the parent.
> 
> It does not matter where the Wallet lives (e.g. inside a variable of the
owner
> itself, inside a PortfolioModel or stored at a completely different
object).
> 
> At the time of adding money the Owner is NOT asked for its wallet, but the
> wallet for the according owner is provided by the WalletManager by asking
> for the correct Wallet for the (Owner, Type) combination.
> 
> A potential code snippet for an aggregate BankMoneyModel class:
> 
> private Wallet<Currency> bankWallet;
> private Wallet<Currency> ipoWallet;
> private Wallet<Currency> poolWallet;
> 
> public BankMoneyModel(Bank bank) {
> 	bankWallet = Wallet.create(bank, "wallet", Currency.class);
> 	ipoWallet = Wallet.create(bank.getIpo(), "wallet", Currency.class);
> 	poolWallet = Wallet.create(bank.getPool(), "wallet",
Currency.class);
> 	bankWallet.addModel(this);
> 	ipoWallet.addModel(this);
> 	poolWallet.addModel(this);
> }
> 
> public int getCash() {
> 	return bankWallet.value() + ipoWallet.value() + poolWallet.value();
}
> 
> In the example above you could wire money to Bank, Pool or Ipo and it has
> the same net effect to the BankMoneyModel.
> 
> The MoneyOwner interface is only a helper/legacy interface to allow an
easy
> access the cash value.
> 
> On 09/02/2012 10:30 PM, Erik Vos wrote:
> >> However it might make the code easier to assume that IPO/Pool etc.
> >> have their own cash wallet to make the item buying code easier:
> >> Then the counterparty of the item transaction is identical to the
> > counterparty
> >> of the accompanying cash transaction.
> >
> > To me, that sounds like making life more complicated rather than
> > making it simpler.
> > Why then not have the Bank portfolios contain a reference to the Bank
> > Wallet?
> > Or indeed, include into every Portfolio a reference to its owner's
Wallet.
> >
> > Erik.
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails2.0: Further Changes

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

It might sound more complicated, but it is a consequence of the indirect 
access to Wallets and Portfolios.

The link between the Wallet and the Owner is defined once and forever by 
creating a Wallet with the Owner as the parent.

It does not matter where the Wallet lives (e.g. inside a variable of the 
owner itself, inside a PortfolioModel or stored at a completely 
different object).

At the time of adding money the Owner is NOT asked for its wallet, but 
the wallet for the according owner is provided by the WalletManager by 
asking for the correct Wallet for the (Owner, Type) combination.

A potential code snippet for an aggregate BankMoneyModel class:

private Wallet<Currency> bankWallet;
private Wallet<Currency> ipoWallet;
private Wallet<Currency> poolWallet;

public BankMoneyModel(Bank bank) {
	bankWallet = Wallet.create(bank, "wallet", Currency.class);
	ipoWallet = Wallet.create(bank.getIpo(), "wallet", Currency.class);
	poolWallet = Wallet.create(bank.getPool(), "wallet", Currency.class);
	bankWallet.addModel(this);
	ipoWallet.addModel(this);
	poolWallet.addModel(this);
}

public int getCash() {
	return bankWallet.value() + ipoWallet.value() + poolWallet.value();
}

In the example above you could wire money to Bank, Pool or Ipo and it 
has the same net effect to the BankMoneyModel.

The MoneyOwner interface is only a helper/legacy interface to allow an 
easy access the cash value.

On 09/02/2012 10:30 PM, Erik Vos wrote:
>> However it might make the code easier to assume that IPO/Pool etc. have
>> their own cash wallet to make the item buying code easier:
>> Then the counterparty of the item transaction is identical to the
> counterparty
>> of the accompanying cash transaction.
>
> To me, that sounds like making life more complicated rather than making it
> simpler.
> Why then not have the Bank portfolios contain a reference to the Bank
> Wallet?
> Or indeed, include into every Portfolio a reference to its owner's Wallet.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails2.0: Further Changes

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

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

I agree. 

Erik.

Re: [Rails-devel] Rails2.0: Portfolios, Ownable and Owner

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

I would say: the natural ordering is the order in which shares are initially
sold. 
I would strongly advise against meddling with that order.
For that reason, I'm not at all convinced that a Set is better than an Array
to hold the company certificates.

Having to create a special Comparator to restore the initial order (how to
configure that?) sounds like doing it backwards to me (we Dutch call that
"putting the horses behind the carriage").

In special cases like the Prussian, or the SJ in 18Scan, where non-president
shares can be bought before the company floats, there is no reaI need to
have the President certificate on top, although I would still consider that
'natural'. These cases need special code anyway.

Also keep in mind conversions from 5-share into 10-share companies, and
other variations on that theme.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday, September 02, 2012 4:04 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Rails2.0: Portfolios, Ownable and Owner
> 
> Erik:
> the underlying TreeSet allows to optionally specify a Comparator which
> deviates from the natural ordering.
> 
> Thus it is easy to add a different ordering to the IPO portfolio.
> 
> But thanks for reminding me of that, do you know other cases where the
> ordering of a "portfolio" in Rails 1.x is important for game mechanics?
> 
> Stefan
> 
> On 09/02/2012 12:41 PM, Erik Vos wrote:
> > Stefan,
> >
> >> * PublicCertificates are sorted by
> >> i) President or not
> >> ii) CertificateType (and those are sorted by number of shares inside)
> >> iii) CertificateId
> >>
> >> This keeps the PresidentShare at position zero of each portfolio
> >> without requiring any code to keep it there. And it keeps the
> >> multi-shares at the
> > top
> >> of a list of certificates.
> >
> > How will you then handle the 1835 double shares that must appear at
> > the
> > *bottom* of the IPO stack (BA, WT and HE)?
> > Currently, specification order determines IPO order.
> >
> > Erik.
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails2.0: Further Changes

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

> However it might make the code easier to assume that IPO/Pool etc. have
> their own cash wallet to make the item buying code easier:
> Then the counterparty of the item transaction is identical to the
counterparty
> of the accompanying cash transaction.

To me, that sounds like making life more complicated rather than making it
simpler.
Why then not have the Bank portfolios contain a reference to the Bank
Wallet? 
Or indeed, include into every Portfolio a reference to its owner's Wallet.

Erik.

Re: [Rails-devel] Rails2.0: Further Changes

[John D. G. <jd...@di...>]

On 2012-09-02 09:16, Mike Bourke wrote:
> "(all transactions between players and companies are forbidden anyway)."
> 
> Not so. Companies can buy private railways and other such from players and
> are expected to do so, depending on which 18xx game you are playing. Without
> this ability, there is no way for a company to be able to place a port
> marker, for example (since by the time the bank seizes control of such
> facilities, the port company is closed).

I have only seen company credits in Tresham's own games: 1825, 1829, and 1853.
And in those games, railroads do not buy in private companies.

> Is not the paying of a dividend (half or full) a transaction between
> shareholding players and the company in which the shares are owned?

No.  The bank pays either players, the railroad, or both.  The railroad and
players do not pay each other anything.

> How about when a company doesn't have enough money for a train and the
> President has to pay for it?

That is indeed a payment from the president to his company -- but it, too,
does not happen in the three Tresham games.  Instead, companies with no train
which can't arrange a purchase from another company simply fall in price until
the owners sell all their shares to the bank (which is allowed).  Then the
company goes into receivership and is allowed to borrow a train from the bank
until it can pay for one.

> There are many actions that can be characterized as transactions between
> players and companies that are not only not forbidden but are mandatory
> elements of the game.

And none of them exist in games with company credits.

> As for using the total of company treasuries to determine whether or not the
> bank is broken, doesn't that ignore the primary point where money is
> supposed to accumulate within the game - in the player's hands?

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.

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.

Re: [Rails-devel] Rails2.0: Further Changes

[Mike B. <com...@ip...>]

"(all transactions between players and companies are forbidden anyway)."

Not so. Companies can buy private railways and other such from players and
are expected to do so, depending on which 18xx game you are playing. Without
this ability, there is no way for a company to be able to place a port
marker, for example (since by the time the bank seizes control of such
facilities, the port company is closed).

Is not the paying of a dividend (half or full) a transaction between
shareholding players and the company in which the shares are owned?

How about when a company doesn't have enough money for a train and the
President has to pay for it?

There are many actions that can be characterized as transactions between
players and companies that are not only not forbidden but are mandatory
elements of the game.

As for using the total of company treasuries to determine whether or not the
bank is broken, doesn't that ignore the primary point where money is
supposed to accumulate within the game - in the player's hands?

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com




---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120901-1, 02/09/2012
Tested on: 3/09/2012 2:16:51 AM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] Rails2.0: Portfolios, Ownable and Owner

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

Erik:
the underlying TreeSet allows to optionally specify a Comparator which 
deviates from the natural ordering.

Thus it is easy to add a different ordering to the IPO portfolio.

But thanks for reminding me of that, do you know other cases where the 
ordering of a "portfolio" in Rails 1.x is important for game mechanics?

Stefan

On 09/02/2012 12:41 PM, Erik Vos wrote:
> Stefan,
>
>> * PublicCertificates are sorted by
>> i) President or not
>> ii) CertificateType (and those are sorted by number of shares inside)
>> iii) CertificateId
>>
>> This keeps the PresidentShare at position zero of each portfolio without
>> requiring any code to keep it there. And it keeps the multi-shares at the
> top
>> of a list of certificates.
>
> How will you then handle the 1835 double shares that must appear at the
> *bottom* of the IPO stack (BA, WT and HE)?
> Currently, specification order determines IPO order.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails2.0: Further Changes

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

Erik,
thanks, quick replies below.
Stefan

On 09/02/2012 12:34 PM, Erik Vos wrote:
> Hi Stefan,
>
> A few minor comments:
>
>> This easily allows to store all kind of CountableItems, for which money is
> only
>> one example (so in principle it is easy that Rails supports several
> currencies).
>
> Ah good. We still had no way to handle the Tresham-style Company Credits
> (1825 et al.).  I suppose we now have.

This is one possibility: Model the Company Credits as another currency. 
It is easy to identify for each transaction which currency to use.

However I still believe that the easiest way is to use one joint 
currency and simply modify the end-of-game condition by adding all 
company treasuries to the bank and check if the bank is broken.
If I remember correctly there is no other real game effect from using 
those Company Credits (all transactions between players and companies 
are forbidden anyway).

>
>> To move money from one owner to the other the following static methods
>> are used:
>>
>> Currency.wire(MoneyOwner from, int amount, MoneyOwner to)
>> Currency.fromBank(int amount, MoneyOwner to)
>> Currency.toBank(MoneyOwner from, int amount)
>
> I hope the Bank is also a MoneyOwner?

Sure Bank is a MoneyOwner (but not the BankPortfolios like IPO).
The latter are only short cuts, which do not require a reference to bank 
to be used.

However it might make the code easier to assume that IPO/Pool etc. have 
their own cash wallet to make the item buying code easier:
Then the counterparty of the item transaction is identical to the 
counterparty of the accompanying cash transaction.

A BankMoneyModel would then aggregate the sub-wallets for display and 
checking the game end condition.

I will reconsider that as soon as I break up the Round classes into 
smaller units.

Re: [Rails-devel] Rails2.0: Portfolios, Ownable and Owner

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

Stefan,

> * PublicCertificates are sorted by
> i) President or not
> ii) CertificateType (and those are sorted by number of shares inside)
> iii) CertificateId
> 
> This keeps the PresidentShare at position zero of each portfolio without
> requiring any code to keep it there. And it keeps the multi-shares at the
top
> of a list of certificates.

How will you then handle the 1835 double shares that must appear at the
*bottom* of the IPO stack (BA, WT and HE)?
Currently, specification order determines IPO order.

Erik.

Re: [Rails-devel] Rails2.0: Further Changes

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

Hi Stefan,

A few minor comments:
 
> This easily allows to store all kind of CountableItems, for which money is
only
> one example (so in principle it is easy that Rails supports several
currencies).

Ah good. We still had no way to handle the Tresham-style Company Credits
(1825 et al.).  I suppose we now have.
 
> To move money from one owner to the other the following static methods
> are used:
> 
> Currency.wire(MoneyOwner from, int amount, MoneyOwner to)
> Currency.fromBank(int amount, MoneyOwner to)
> Currency.toBank(MoneyOwner from, int amount)

I hope the Bank is also a MoneyOwner?  

Erik