RE: [Rails-devel] Certificate ownership

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

> > My main reason for the introduction of Tradeable is that it 
> allows the
> > tradeables 
> > to be collected in one Collection (point 3); this is a 
(...)
> 
> This isn't necessary. I believe that arrays are the only data 
> type that
> requires storing only a single type of object into it. Arraylists and
> hashmaps can store multiple types of objects.

Yes, of course. I mixed up ArrayList and Tradeable[].
 
> > > > 3. Each entity that can hold Tradeables (certificates and 
> > > private companies)
> > > > 
> > > > has a Portfolio containing some collection of Tradeables. 
> > > > This applies to Player, PublicCompany and the Bank
> > > > (the Bank would have two Portfolios: IPO and Pool).
> > > > Portfolio could be a separate class, perhaps a subclass of some
> > > > Collection type (ArrayList or HashMap). 
> > > > Or it would contain such a Collection type. Not sure 
> what's better.
> > > > 
> > > 
> > > I don't think it's a good idea to have one repository for 
> both private
> > > companies and stock certificates. There is significantly more 
> > > operations
> > > performed on stock certificates than there is on private 
> companies. 
> > > 
> > > I think these should remain separate.
> > 
(...)
> > So I don't see much difference between Certificates and 
> PrivateCompanies 
> > from the ownership/trading point of view, which is all I'm 
> talking about
> > here.
> > 
> 
> What about checking for meeting share holding limits?
> 
> If your collection contains both stocks and companies, it makes the
> logic for checking holding limits much more complicated. If 
> we keep the
> two separate, it's a simple iteration over the collection, 
> counting the
> values with no need to keep checking an instanceOf method.

Well, having one or two collections does not make much difference.
The question rather is, where to put this/these collection(s) in: 
the owning entity or in a separate Portfolio class. 

Another consideration is the following remark by Stewart Thain
in his message of March 1:

<quote>
I've modelled "Bank", "Player" and "Company" as subclasses of a common 
"Entity" class. This allows inherited code to take care of common 
functionality and in particular relationships. "Stock" can be held by any of

"Bank", "Player" or "Company" in some 18xx games. In 1841, IIRC, major 
companies can even hold stock in other companies. This brings an opportunity

to write very simple code for functionality like dividends: some 
"payDividend" (with amount parameter) method on "Company" simply loops round

all issued "Stock" (follows the "issues" relationship), calling a 
"payDividend" method on each "Stock" object, which pays the correct amount 
(adjusted for percentage share) to the owning "Entity" (follows the inverse 
"owns" relationship).
</quote>

IMO this does not work for the Bank, as it has two different portfolios (IPO
and Pool). 

Another problem is, that only PublicCompanies can hold certificates,
it looks a bit silly to include PrivateCompany here 
(I know that Stewart had not made this split at all).

But in my proposals I was trying to retain the spirit of this by 
commonalities being modelled as common classes or interfaces.

See below for my revised proposal.

> > > > 4. Each entity that has a Portfolio implements an 
> interface Owner,
> > > > so that each Tradeable can have an attribute defining its Owner.
(...)
> > I think the payout will be much simpler my way, i.e. if a 
> Certificate
> > knows its Owner.
> 
> for each player, for each portfolio, if the stock certificate name
> equals the company paying out, allocate a share of the dividend.

This is the cumbersome and inefficient try-all-potential-owners double loop
that I was trying to avoid.

> alternately, if we have the ownership being dual ownership: 
> players and
> the bank owns certificates AND the companies own certificate, the loop
> is:
> 
> for each company, for each share, get player name, allocate a share of
> the dividend.

Er... how does "get player name" work, if a share does not know its owner?
I think you are proving my point here.

Please also note, that Stewart assumed a path (relationship) from Stock to
Entity -
in my case that would be from Certificate to Portfolio (rather than Owner, 
because in paying out we must be able to distinguish IPO and Bank Pool). 

The Portfolio would know to which (type of) Treasury to add dividends.
To me this looks like another good reason to have this Portfolio class.

Here is my revised proposal:

1. We have a Portfolio class, which has the following:
- a collection of PrivateCompanies,
- a collection of PublicCompany Certificates,
- the knowledge to which type of treasury dividends must be 
paid out for shares in this Portfolio and ways to find it
(this treasury varies per game for the BankPool and IPO portfolios).
- maybe a reference to an Owner (or Shareholder: Bank, Player,
PublicCompany),
which is the entity that owns the money involved in buying and selling the
above,
(but possibly we don't really need it. If we do, we also need an Owner
interface).
- perhaps other common info or methods.

2. Each PrivateCompany and Certificate has a portfolio attribute, 
to know where to look for info on where to drop cash.

3. Payout is simply a loop per company over its certificates,
backtracking references as stated above to find each one's payout treasury.

This way we don't need Tradeable. Not sure yet about Trader.

I think it is time to start writing some code to see what works and what
not.
Perhaps next weekend, if the weather is bad enough....

Erik.