rails-devel — List for discussion of Rails development

[Rails-devel] Fully Working Stock Tokens

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

I've just committed the rest of the UI code to display stock tokens moving around the stock market.

You can click on the company name to select the token, and use the buttons to push them all over the board.

There is a bug with the message box that displays if no token is selected: the error message doesn't show up in the box. I haven't tracked that bug down, but I suspect that it's likely due to the brute force nature of the current UI code.

Either way, I think now is the time to start looking at the UI and figuring out how we want to display the various bits of information. I suppose that until we get some volunteers for creating game artwork, or permission to use existing art from the existing games, we can stick with raw numeric output. However, I think it might be worthwhile to eventually display stock certificates graphically and perhaps aim for a drag-n-drop UI.

Thoughts?


---Brett

[Rails-devel] swing book

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

I've found a book on swing that's getting decent reviews and is updated
to JRE 1.4:

http://manning.com/robinson2

Amazon.com is listing used and new copies for as cheap as US$34 instead
of the retail price of US$50


---Brett. 

At Microsoft, quality is job 1.1 - Use Linux!

RE: [Rails-devel] Initial working stock tokens

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

On Thu, 2005-04-21 at 20:40 +0200, Erik Vos wrote:
> > While testing token overlaying in the same space, I found a 
> > bug in getPublicCompany():  It doesn't handle strings with 
> > ampersands (e.g. "B&O"), and throws a Null Pointer Exception instead.
> 
> Strange, I don't have this problem.... B&O works fine with me.
> Where did the Exception come from?
>  

Weird. I just tried it, and it works fine.  I'm working on this code
from a couple different locations, so it could be a difference in JREs.
I'll keep an eye out in case I see it again.



---Brett. 

DeVries' Dilemma: If you hit two keys on the typewriter, the one you
don't want hits the paper.

[Rails-devel] Initial cash and Certificate limit

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

I have added these items to Game.xml.

For lack of a better idea I put the new <Players> tags inside the Bank,
but the values are actually stored in Player (a simple int array).
Trouble is, I cannot configure Player from ComponentManager as 
a top-level component because it is not a singleton.
And adding a PlayerManager looks a bit like overkill to me...

If anyone has a better proposal, let me know.


Next job will be a solution for Brett's request on Colors.

Erik.	

RE: [Rails-devel] RE: Initial working stock tokens

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

> > Strange, I don"t have this problem.... B&O works fine with me.
> > Where did the Exception come from?
>   
> In ui/StockTest.java
> 
> I've left the non-working statement commented out and labeled 
> with "FIXME:"

Yes, I had seen that, but when I reactivate that statement,
I have no problem at all. B&O displays fine (as far as that goes ;-)).

I meant: what does the Exception stack trace look like?

It's hard to debug if a problem cannot be reproduced....


BTW, I have made a fresh new install of Eclipse and now I'm back in
business,
except that I have lost some configurations. 

Erik.

[Rails-devel] RE: Initial working stock tokens

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

> > While testing token overlaying in the same space, I found a 
> > bug in getPublicCompany():  It doesn"t handle strings with 
> > ampersands (e.g. "B&O"), and throws a Null Pointer Exception instead.
 
> Strange, I don"t have this problem.... B&O works fine with me.
> Where did the Exception come from?
  
In ui/StockTest.java

I've left the non-working statement commented out and labeled with "FIXME:"

> > Also, we need to figure out a way to broaden our support for 
> > colors. java.awt.Color only has a few predefined colors. So, 
> > do we want to allow RGB values, or hex values in the XML? 
 
> Yes, I will work on that. I"m considering hex values in the XML
> (easier to parse just one value), to be translated to Color 
> objects in the company instance.
 
Great.  I think java.awt.Color already has a method to parse a hex value into a Color object. You may want to look at that, it'll probably make supporting this very easy.
 

[Rails-devel] RE: Eclipse won"t start anymore...

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

Try moving the rails directory to somewhere outside of the workspace directory, start eclipse, then move the directory back. 

You may need to pull a clean copy of the project from CVS.

[Rails-devel] Eclipse won't start anymore...

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

Help!

Eclipse won't start any more.
I get a message to look in the log, where I see

!SESSION Apr 21, 2005 20:42:45.312
---------------------------------------------
java.version=1.4.1_02
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_GB
Command-line arguments: -os win32 -ws win32 -arch x86 -install
file:C:/Java/Eclipse/
!ENTRY org.eclipse.core.runtime 4 2 Apr 21, 2005 20:42:45.312
!MESSAGE Problems occurred when invoking code from plug-in:
"org.eclipse.core.runtime".
!STACK 0
org.eclipse.core.internal.dtree.ObjectNotFoundException: Tree element /Rails
18xx/data/18AL/Game.xml not found.
	at
org.eclipse.core.internal.dtree.AbstractDataTree.handleNotFound(AbstractData
Tree.java:243)
	at
org.eclipse.core.internal.dtree.DeltaDataTree.getData(DeltaDataTree.java:608
)
	at
org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.
java:54)

followed by

!ENTRY org.eclipse.core.runtime 4 2 Apr 21, 2005 20:42:45.343
!MESSAGE Plug-in "org.eclipse.ui" was unable to instantiate class
"org.eclipse.ui.internal.Workbench".
!STACK 0
org.eclipse.core.internal.boot.DelegatingLoaderException:
org.eclipse.core.runtime.CoreException: Problems encountered starting up
plug-in: "org.eclipse.core.resources".
	at
org.eclipse.core.internal.plugins.PluginDescriptor.internalDoPluginActivatio
n(PluginDescriptor.java:746)
	at
org.eclipse.core.internal.plugins.PluginDescriptor.doPluginActivation(Plugin
Descriptor.java:188)

and more. 


Note the strange message on data/18AL/Game.xml (the file does still exist).

Does anyone have a clue what I can do about this?
I reinstalled Eclipse, but that does not help.

Erik.

[Rails-devel] Certificates and Bank

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

I have updated some game classes (including Bank and CompanyManager)
and most of the Game and CompanyManager XML files to include 
Certificates and to configure the initial Bank cash amount.

The bank caused me some trouble. It is now handled by ComponentManager,
and it turned out, that anything that is configured by the ComponentManager 
is not accessible until all XML files have been read. 

Previously, I put all Certificates in the IPO (a Bank Portfolio)
while configuring the companies (i.e. parsing CompanyManager.xml),
but that is no longer possible. So I added an an additional Bank
method initIpo(), which is now called by Game after all XML reading.

Well, perhaps that is just as well.....

Erik.

RE: [Rails-devel] Initial working stock tokens

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

> While testing token overlaying in the same space, I found a 
> bug in getPublicCompany():  It doesn't handle strings with 
> ampersands (e.g. "B&O"), and throws a Null Pointer Exception instead.

Strange, I don't have this problem.... B&O works fine with me.
Where did the Exception come from?
 
> Also, we need to figure out a way to broaden our support for 
> colors. java.awt.Color only has a few predefined colors. So, 
> do we want to allow RGB values, or hex values in the XML? 

Yes, I will work on that. I'm considering hex values in the XML
(easier to parse just one value), to be translated to Color 
objects in the company instance.

> My stringToColor() method is only going to scale so far. ;-)

Erik.

Re: [Rails-devel] Initial working stock tokens

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

While testing token overlaying in the same space, I found a bug in getPublicCompany():  It doesn't handle strings with ampersands (e.g. "B&O"), and throws a Null Pointer Exception instead.

Also, we need to figure out a way to broaden our support for colors. java.awt.Color only has a few predefined colors. So, do we want to allow RGB values, or hex values in the XML? 

My stringToColor() method is only going to scale so far. ;-)

---Brett.


-----Original Message-----
From: wak...@ea...
Sent: Apr 20, 2005 5:39 PM
To: rai...@li...
Subject: [Rails-devel] Initial working stock tokens

I've committed the inital set of code for displaying tokens on the stock chart.


There's still quite a bit of kinks that need working out, but the basic token displaying works.


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Initial working stock tokens

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

I've committed the inital set of code for displaying tokens on the stock chart.

There's still quite a bit of kinks that need working out, but the basic token displaying works.

RE: [Rails-devel] Tokens on the StockMarket

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

On Tue, 2005-04-19 at 21:52 +0200, Erik Vos wrote:
> Brett, 

> > Hmmm... can you compare this with my swing version and see if 
> > I'm making
> > the problem harder than it needs to be?
> 
> I think you are almost there.
> 
> I have checked in:
> - a new version of test.StockTest that adds some markers
> to the stock chart by setting par prices, and 
> - a new version of ui.StockChart with some (temporary) System.out prints 
> to demonstrate that these markers are indeed picked up by your current code.
> 
> 
> All you need to do, it seems to me, is to let the markers display themselves
> on the right place (I can't help much with that at the moment....)
> 

OK great. Calling a repaint is easy, if that's all needing to be done.


> BTW I have also added a few more missing I's to StockSpace and Company.
> 

Excellent. I had a suspicion I'd missed a few and hadn't had time to
check.

> And locally I have removed Little, Big and Simple Company, which I think
> are redundant now, but I keep these ones merged by CVS. 
> Do you want to keep these?

If they don't fit our needs, we don't need to keep them. CVS never truly
deletes things, so if we need them later, we can retrieve them.



---Brett. 

Life's the same, except for the shoes. - The Cars

RE: [Rails-devel] Tokens on the StockMarket

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

Brett, 

> > In my stockmarket servlet the code is like
> > 
> > 	for (row = 0; row < stockMarket.getNumberOfRows(); row++) {
> > 		for (col = 0; col < 
> stockMarket.getNumberOfColumns(); col++)
> > {
> > 			square = stockMarket.getStockSpace(row, col);
> > 			if (square != null) {
> >                         // draw square
> > 				iterator = 
> square.getTokens().iterator();
> > 				while (iterator.hasNext()) {
> > 					company = (PublicCompany)
> > iterator.next();
> > 					// draw company marker
> > 				}
> > 			}
> > 		}
> > 	}
> > 
> > and I don't see why similar code would not work for you.
> > I guess I'm missing a point somewhere....
> > 
> 
> Hmmm... can you compare this with my swing version and see if 
> I'm making
> the problem harder than it needs to be?

I think you are almost there.

I have checked in:
- a new version of test.StockTest that adds some markers
to the stock chart by setting par prices, and 
- a new version of ui.StockChart with some (temporary) System.out prints 
to demonstrate that these markers are indeed picked up by your current code.


All you need to do, it seems to me, is to let the markers display themselves
on the right place (I can't help much with that at the moment....)

BTW I have also added a few more missing I's to StockSpace and Company.

And locally I have removed Little, Big and Simple Company, which I think
are redundant now, but I keep these ones merged by CVS. 
Do you want to keep these?

Erik.

RE: [Rails-devel] Tokens on the StockMarket

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

On Mon, 2005-04-18 at 23:21 +0200, Erik Vos wrote:

> Wouldn't a method have been simpler?
> 
> boolean hasTokens() {
>  	return (tokens.size() != 0);
> }


Hmmm... I think that may be.



> Maybe the confusion comes because I'm linking company and space objects as a
> whole,
> rather than having a separate int price attribute in a company object?
> 
> In my stockmarket servlet the code is like
> 
> 	for (row = 0; row < stockMarket.getNumberOfRows(); row++) {
> 		for (col = 0; col < stockMarket.getNumberOfColumns(); col++)
> {
> 			square = stockMarket.getStockSpace(row, col);
> 			if (square != null) {
>                         // draw square
> 				iterator = square.getTokens().iterator();
> 				while (iterator.hasNext()) {
> 					company = (PublicCompany)
> iterator.next();
> 					// draw company marker
> 				}
> 			}
> 		}
> 	}
> 
> and I don't see why similar code would not work for you.
> I guess I'm missing a point somewhere....
> 

Hmmm... can you compare this with my swing version and see if I'm making
the problem harder than it needs to be?




---Brett. 

...this is an awesome sight. The entire rebel resistance buried under
six million hardbound copies of "The Naked Lunch." - The Firesign
Theater

RE: [Rails-devel] Tokens on the StockMarket

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

> I've added the code to draw a token in ui/StockChit and the 
> logic to do
> so in ui/StockChart.
> 
> I added a boolean in game/StockSpace called hasTokens to make 
> it easy to
> figure out if a particular stock space has any tokens on it. I added a
> getter and setter for this new variable as well as inserted logic to
> toggle the boolean in some of the other methods within the StockSpace
> class.

Wouldn't a method have been simpler?

boolean hasTokens() {
 	return (tokens.size() != 0);
}
 
> My current idea on how to put the tokens onto the Stock Market is to
> insert them as part of drawing the whole chart. Unfortunately this is
> making it rather difficult to test this because PublicCompany only
> accepts a StockSpace for setCurrentPrice, so I'm hitting a chicken and
> egg problem when it comes time to draw each StockSpace within the
> StockChart. 
> 
> I suspect the solution is that this single method ought to be 
> broken up
> into two separate methods that allow easy cross-indexing with the
> information contained in a StockSpace:
> 
> setCurrentPrice(int p)
> setCurrentGridLocation(String coord) or setCurrentGridLocation(int x,
> int y)
> 
> Or perhaps I'm missing an easier solution entirely...

Not sure what the problem is. If you are drawing a space you need
the corresponding StockSpace object, if only to find the price, 
and then getTokens() will tell you what companies have a marker on that
space.

Maybe the confusion comes because I'm linking company and space objects as a
whole,
rather than having a separate int price attribute in a company object?

In my stockmarket servlet the code is like

	for (row = 0; row < stockMarket.getNumberOfRows(); row++) {
		for (col = 0; col < stockMarket.getNumberOfColumns(); col++)
{
			square = stockMarket.getStockSpace(row, col);
			if (square != null) {
                        // draw square
				iterator = square.getTokens().iterator();
				while (iterator.hasNext()) {
					company = (PublicCompany)
iterator.next();
					// draw company marker
				}
			}
		}
	}

and I don't see why similar code would not work for you.
I guess I'm missing a point somewhere....

Erik.
 

RE: [Rails-devel] Interfaces in method signatures

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

On Mon, 2005-04-18 at 09:17 +0100, Stewart Thain wrote:
> Brett,
> 
> In my opinion, this change is a backwards step. The main purpose for using 
> interfaces for all argument and return types is to allow objects of new 
> classes that implement the interface to passed in to existing methods.
> 
> To take your example of java.util.List. If you examine all of its methods, 
> *every* parameter and return type (with the exception of Object) is an 
> interface. Many of the arguments are Collection which is the parent 
> interface for List. Object of course can be anything anyway! :-)
> 
> To give you another example, take a look at the Collections utility class 
> (java.util.Collections), many of the methods take or return List, and again 
> with the exeception of Object, all of the myriad of arguments and return 
> types are interfaces.
> 
> regards
> 
> Stewart


Hmmmm...  you're right.

I had my thinking all backwards. I'll undo this change.


---Brett. 

You want to know why I kept getting promoted? Because my mouth knows
more than my brain. -- W.G.

RE: [Rails-devel] Interfaces in method signatures

[Stewart T. <wsr...@ho...>]

Brett,

In my opinion, this change is a backwards step. The main purpose for using 
interfaces for all argument and return types is to allow objects of new 
classes that implement the interface to passed in to existing methods.

To take your example of java.util.List. If you examine all of its methods, 
*every* parameter and return type (with the exception of Object) is an 
interface. Many of the arguments are Collection which is the parent 
interface for List. Object of course can be anything anyway! :-)

To give you another example, take a look at the Collections utility class 
(java.util.Collections), many of the methods take or return List, and again 
with the exeception of Object, all of the myriad of arguments and return 
types are interfaces.

regards

Stewart

>From: Brett <wak...@ea...>
>Reply-To: rai...@li...
>To: rails-devel <rai...@li...>
>Subject: [Rails-devel] Interfaces in method signatures
>Date: Sun, 17 Apr 2005 20:48:24 -0700
>
>The other change I've committed tonight that seemed good to dedicate a
>separate e-mail toward is this:
>
>I've removed the usage of interfaces as arguments or return types as
>much as possible.
>
>My reasoning is this:  Interfaces are not real objects and therefore
>should only be mentioned when real objects are implementing an
>interface. The real objects implementing the interface ought to be the
>arguments and return types of methods.
>
>Take a look at the interfaces in the Java API, List is a good one, and
>you'll notice that an interface is never an argument or a return type.
>
>
>
>---Brett.
>
>One good turn deserves another. -- Gaius Petronius
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Rails-devel mailing list
>Rai...@li...
>https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Interfaces in method signatures

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

The other change I've committed tonight that seemed good to dedicate a
separate e-mail toward is this:

I've removed the usage of interfaces as arguments or return types as
much as possible.

My reasoning is this:  Interfaces are not real objects and therefore
should only be mentioned when real objects are implementing an
interface. The real objects implementing the interface ought to be the
arguments and return types of methods.

Take a look at the interfaces in the Java API, List is a good one, and
you'll notice that an interface is never an argument or a return type. 



---Brett. 

One good turn deserves another. -- Gaius Petronius

[Rails-devel] Tokens on the StockMarket

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

I've added the code to draw a token in ui/StockChit and the logic to do
so in ui/StockChart.

I added a boolean in game/StockSpace called hasTokens to make it easy to
figure out if a particular stock space has any tokens on it. I added a
getter and setter for this new variable as well as inserted logic to
toggle the boolean in some of the other methods within the StockSpace
class.

My current idea on how to put the tokens onto the Stock Market is to
insert them as part of drawing the whole chart. Unfortunately this is
making it rather difficult to test this because PublicCompany only
accepts a StockSpace for setCurrentPrice, so I'm hitting a chicken and
egg problem when it comes time to draw each StockSpace within the
StockChart. 

I suspect the solution is that this single method ought to be broken up
into two separate methods that allow easy cross-indexing with the
information contained in a StockSpace:

setCurrentPrice(int p)
setCurrentGridLocation(String coord) or setCurrentGridLocation(int x,
int y)

Or perhaps I'm missing an easier solution entirely...


---Brett. 

Bugs, pl. n.: Small living things that small living boys throw on small
living girls.

Re: [Rails-devel] Shares and money

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

On Sun, 2005-04-17 at 16:32 +0200, Erik Vos wrote:

> How does this all fit into our project's architecture?
> I see it like this:
> 
> +------------------------------------+
> | Upper layer = View (UI)            |
> |   display, produce events          |
> +------------------------------------+
> | Middle layer = Model (game logic)  |
> |   catch events, call data objects  |
> +------------------------------------+
> | Lower layer = Model (data objects) |
> |   file interfaces, object states   |
> +------------------------------------+
> 


IMO, this looks about right.


> The test servlet replaces the top 2 layers, and already
> contains code fragments that I think will end up
> in the middle layer classes. But I have no idea yet
> on how this middle layer will actually look like.
> Unfortunately, UI development seems to be lagging behind.
> 

Yes. Unfortunately I haven't had much time in the last month to work on
the UI. I think that'll be changing.


> It turns out Brett does not want the servlet code in the project repository
> (or maybe just not below the game package). If it does not get another
> place, so be it; I'm happy to send this code to anyone who is interested
> in how I'm using the base classes developed so far.
> Anyhow, I'll continue this way, which is the only one that works 
> for me right now.

I sent you an e-mail privately about this, but it might be useful to
duplicate some of that here, publicly.

After looking at the extent to which you've developed the servlet, I
think it deserves a place in the test directory at the project root.

I only wish developing in swing were as easy. ;-)



---Brett. 

LBNC (luser brain not connected)

[Rails-devel] Shares and money

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

During the last week I have been working on some further
low-level classes. The following ones are new:

- Certificate / CertificateI (public company share papers).
- Portfolio, discussed before. Certificates are held in
a ListArray per company, accessed via a HashMap. 
This works easiest. There still also is an overall ArrayList 
of certificates, but I think that one is redundant.
- CashHolder: an interface implemented by all money holders,
to allow cash transfer. This is done via a static method
Bank.transferCash (CashHolder from, CashHolder to, int amount).
To avoid the need to have a Bank instance everywhere I have added
the shortcut, that either 'from' or 'to' may be null, 
in which case it is the Bank.
- Log: to log the proceeds (currently to System.out) and make
the increments after each action available for display (see below).

I have also created a new test servlet (GameTestServlet).
On my website (http://home.hccnet.nl/erik.vos/18xx.html) I have
added 6 screenshots of HTML output from this servlet, which shows,
that most of the simple actions during a game already can be done.
Also the Log output is shown.
Below more on this servlet.

Currently implemented features (partly in the servlet, but all
using underlying code in the base classes):
- Share buying and selling (but no presidency change yet).
All done via a Portfolio method
buyCertificate (CertificateI certificate, Portfolio from, int price)
[which calls transferCash for the monetary part of the transaction).
- Correct dividend payout and withholding.
- Private buying and payout, also by and to companies.
- Correct stock marker movements, including when sold out.

Not covered yet are:
- Trains, tokens and tiles (but the servlet allows a company
to spend any amount on whatever).
- Private special properties, i.e. B&O does not come with the
president's share (so better subtract $200 from the private price!)
and does not close when B&O operates (buys a train).
- Player order, operating order, priority.
- Money amount limit checking (e.g. when buying privates).
Also negative cash still allowed.

I have not done much to the XML files yet. Only addition is
the definition of Certificates per company type and/or per company 
(see the 1830 Company.Manager.xml file).
Many details (like the bank size and player initial cash) 
are now hardcoded the 1830 way, but that will be changed soon.
 
If Certificates are defined per CompanyType, these will be cloned 
into each company which has not itself defined a certificate array. 
I plan to change this so, that a <CompanyType> can contain 
a whole dummy company with all possible features,
all of which will be cloned into the <Company> if not overridden.


How does this all fit into our project's architecture?
I see it like this:

+------------------------------------+
| Upper layer = View (UI)            |
|   display, produce events          |
+------------------------------------+
| Middle layer = Model (game logic)  |
|   catch events, call data objects  |
+------------------------------------+
| Lower layer = Model (data objects) |
|   file interfaces, object states   |
+------------------------------------+

The game classes I have developed so far cover part of the lowest layer.

The test servlet replaces the top 2 layers, and already
contains code fragments that I think will end up
in the middle layer classes. But I have no idea yet
on how this middle layer will actually look like.
Unfortunately, UI development seems to be lagging behind.

All I can contribute right now is in defining the lower layer
components and their interfaces (APIs) with the middle layer.
In this respect, what I have done so far looks pretty good,
taking into account the things that can already be done 
(see the screen shots). Hopefully the upper/middle layer 
development will get a boost now....

It turns out Brett does not want the servlet code in the project repository
(or maybe just not below the game package). If it does not get another
place, so be it; I'm happy to send this code to anyone who is interested
in how I'm using the base classes developed so far.
Anyhow, I'll continue this way, which is the only one that works 
for me right now.

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

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