rails-devel

[Rails-devel] Certificate ownership

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

The brilliant weather here in the Netherlands prevents me from
doing any coding this weekend (that would be a waste).
But I do want to take time to explain my ideas of how to deal with 
shares, ownership etc. 

1. The basic unit of property would be Certificate (rather than Share). 
Attributes would include Owner (see below), share (percentage), 
certificateCount (against the limit - can be 0, 0.5 or 1).

2. Each tradeable object would implement an interface Tradeable.
This would apply to Certificates and PrivateCompanies.
PublicCompanies are not themselves Tradeable, but hold an array
of Tradeable Certificates. 
Minor companies like those in 1835 will have one 100% Certificate
(to avoid the need for a subclass MinorCompany extends PublicCompany
implements 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.

4. Each entity that has a Portfolio implements an interface Owner,
so that each Tradeable can have an attribute defining its Owner.

5. Maybe we will also need a separate interface Trader, 
to define methods that an actively trading Owner must have
(sell, buy). This assumes that the Bank does not need such
methods (it does not initiate sell/buy actions). 
If it does, Owner and Trader will converge into one interface.

Erik.

Re: [Rails-devel] Certificate ownership

[Brett <wak...@ea...>]

On Sat, 2005-04-02 at 17:33 +0200, Erik Vos wrote:
> 1. The basic unit of property would be Certificate (rather than Share). 
> Attributes would include Owner (see below), share (percentage), 
> certificateCount (against the limit - can be 0, 0.5 or 1).


Looks ok.


> 2. Each tradeable object would implement an interface Tradeable.
> This would apply to Certificates and PrivateCompanies.
> PublicCompanies are not themselves Tradeable, but hold an array
> of Tradeable Certificates. 
> Minor companies like those in 1835 will have one 100% Certificate
> (to avoid the need for a subclass MinorCompany extends PublicCompany
> implements Tradeable).
> 

Hmmm... I see the distinction you're trying to make, but I'm not
completely certain this is necessary to do it. There doesn't seem to be
any attributes specific to a Tradable that require an interface.

I think this may just need to be a logical distinction and not
necessarily something defined in code except as a coding practice.


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


> 4. Each entity that has a Portfolio implements an interface Owner,
> so that each Tradeable can have an attribute defining its Owner.
> 

I think this is confusing the relationship between the objects. Owners
should have a collection that stores their Tradables. We don't need to
duplicate that specification by assigning an owner attribute to the
tradable as well.

Is there any use case where this would not be true?

> 5. Maybe we will also need a separate interface Trader, 
> to define methods that an actively trading Owner must have
> (sell, buy). This assumes that the Bank does not need such
> methods (it does not initiate sell/buy actions). 
> If it does, Owner and Trader will converge into one interface.

The only thing that can be sold is stock certificates, and it's only to
the bank. Everything else must be bought. It may be pedantic, but I
think it's important to make the distinction because buying is a generic
action, and selling is a singular special case. I think this helps guide
us to where we need to implement the logic and how.

I'm not certain another interface is the right answer.




---Brett. 

After twelve years of therapy my psychiatrist said something that
brought tears to my eyes. He said, "No hablo ingles." -- Ronnie Shakes

RE: [Rails-devel] Certificate ownership

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

> > 2. Each tradeable object would implement an interface Tradeable.
> > This would apply to Certificates and PrivateCompanies.
> > PublicCompanies are not themselves Tradeable, but hold an array
> > of Tradeable Certificates. 
> > Minor companies like those in 1835 will have one 100% Certificate
> > (to avoid the need for a subclass MinorCompany extends PublicCompany
> > implements Tradeable).
> > 
> 
> Hmmm... I see the distinction you're trying to make, but I'm not
> completely certain this is necessary to do it. There doesn't 
> seem to be
> any attributes specific to a Tradable that require an interface.
> 
> I think this may just need to be a logical distinction and not
> necessarily something defined in code except as a coding practice.

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 debatable point
indeed.
A less important reason is that they have buying and selling as common
operations 
(also see point 3).
 
> > 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.

The operations we are talking about here are selling and buying,
not payout (see my answer to point 4), although even that has some
commonality....

Both Privates and Certificates can be bought and sold (e.g. in 1825 private
companies 
can be sold to the bank pool; in 1841 Concessions -this game's equivalent
of privates- as well as Certificates may even be bought directly from other
players, 
although some house rules forbid that). 

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.

> > 4. Each entity that has a Portfolio implements an interface Owner,
> > so that each Tradeable can have an attribute defining its Owner.
> > 
> 
> I think this is confusing the relationship between the objects. Owners
> should have a collection that stores their Tradables. We don't need to
> duplicate that specification by assigning an owner attribute to the
> tradable as well.
> 
> Is there any use case where this would not be true?
> 

When paying out a dividend.
How else would you find the owner of each certificate of one company? 
By scanning all potential owners?
I think the payout will be much simpler my way, i.e. if a Certificate
knows its Owner.

I tend to use two-way references indeed, as I already have
done in the case of PublicCompany <-> StockSpace.
There some operations are best done from the PublicCompany side
(finding a company's share price), and other operations are
best done from the StockSpace side (drawing the markers).

IMO the same is true in the certificate <-> owner relationship:
trading is an operation by an Owner towards a Certificate/PrivateCompany, 
but payout is an operation of a Company's Certificate towards its Owner.

> > 5. Maybe we will also need a separate interface Trader, 
> > to define methods that an actively trading Owner must have
> > (sell, buy). This assumes that the Bank does not need such
> > methods (it does not initiate sell/buy actions). 
> > If it does, Owner and Trader will converge into one interface.
> 
> The only thing that can be sold is stock certificates, and 
> it's only to
> the bank. Everything else must be bought. It may be pedantic, but I
> think it's important to make the distinction because buying 
> is a generic
> action, and selling is a singular special case. I think this 
> helps guide
> us to where we need to implement the logic and how.
> 
> I'm not certain another interface is the right answer.
> 

In this case I'm not sure either. We'll see.

BTW, selling _can_ be implemented on this low level as buying by the Bank.
That might simplify the code, but perhaps it would confuse some people.
I have no firm opinion on this matter yet.

Please note, that I am always talking about the Model,
and in fact mostly about the Data Objects "below" the Model.
This is all low-level stuff.

Erik.

RE: [Rails-devel] Certificate ownership

[Brett <wak...@ea...>]

On Sun, 2005-04-03 at 13:37 +0200, Erik Vos wrote:
> > > 2. Each tradeable object would implement an interface Tradeable.
> > > This would apply to Certificates and PrivateCompanies.
> > > PublicCompanies are not themselves Tradeable, but hold an array
> > > of Tradeable Certificates. 
> > > Minor companies like those in 1835 will have one 100% Certificate
> > > (to avoid the need for a subclass MinorCompany extends PublicCompany
> > > implements Tradeable).
> > > 
> > 
> > Hmmm... I see the distinction you're trying to make, but I'm not
> > completely certain this is necessary to do it. There doesn't 
> > seem to be
> > any attributes specific to a Tradable that require an interface.
> > 
> > I think this may just need to be a logical distinction and not
> > necessarily something defined in code except as a coding practice.
> 
> 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 debatable point
> indeed.
> A less important reason is that they have buying and selling as common
> operations 
> (also see point 3).


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.


>  
> > > 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.
> 
> The operations we are talking about here are selling and buying,
> not payout (see my answer to point 4), although even that has some
> commonality....
> 
> Both Privates and Certificates can be bought and sold (e.g. in 1825 private
> companies 
> can be sold to the bank pool; in 1841 Concessions -this game's equivalent
> of privates- as well as Certificates may even be bought directly from other
> players, 
> although some house rules forbid that). 
> 
> 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.


> > > 4. Each entity that has a Portfolio implements an interface Owner,
> > > so that each Tradeable can have an attribute defining its Owner.
> > > 
> > 
> > I think this is confusing the relationship between the objects. Owners
> > should have a collection that stores their Tradables. We don't need to
> > duplicate that specification by assigning an owner attribute to the
> > tradable as well.
> > 
> > Is there any use case where this would not be true?
> > 
> 
> When paying out a dividend.
> How else would you find the owner of each certificate of one company? 
> By scanning all potential owners?
> 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.

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.


> 
> I tend to use two-way references indeed, as I already have
> done in the case of PublicCompany <-> StockSpace.
> There some operations are best done from the PublicCompany side
> (finding a company's share price), and other operations are
> best done from the StockSpace side (drawing the markers).
> 
> IMO the same is true in the certificate <-> owner relationship:
> trading is an operation by an Owner towards a Certificate/PrivateCompany, 
> but payout is an operation of a Company's Certificate towards its Owner.
> 
> > > 5. Maybe we will also need a separate interface Trader, 
> > > to define methods that an actively trading Owner must have
> > > (sell, buy). This assumes that the Bank does not need such
> > > methods (it does not initiate sell/buy actions). 
> > > If it does, Owner and Trader will converge into one interface.
> > 
> > The only thing that can be sold is stock certificates, and 
> > it's only to
> > the bank. Everything else must be bought. It may be pedantic, but I
> > think it's important to make the distinction because buying 
> > is a generic
> > action, and selling is a singular special case. I think this 
> > helps guide
> > us to where we need to implement the logic and how.
> > 
> > I'm not certain another interface is the right answer.
> > 
> 
> In this case I'm not sure either. We'll see.
> 
> BTW, selling _can_ be implemented on this low level as buying by the Bank.
> That might simplify the code, but perhaps it would confuse some people.
> I have no firm opinion on this matter yet.
> 
> Please note, that I am always talking about the Model,
> and in fact mostly about the Data Objects "below" the Model.
> This is all low-level stuff.


Right. That I understand.



---Brett. 

One possible reason that things aren't going according to plan is that
there never was a plan in the first place.

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.

RE: [Rails-devel] Certificate ownership

[Brett <wak...@ea...>]

On Tue, 2005-04-05 at 21:38 +0200, Erik Vos wrote:
> > 
> > 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.
> 

I probably am.

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

This looks good.  I've already defined Player and Bank class stubs. We
can probably get away with just using overloaded methods to obtain the
owner of the stocks, one that returns a Player object and one that
returns a Bank object.

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

Sounds good to me.


---Brett. 

temporary routing anomoly