rails-devel

[Rails-devel] Status of Tile & Map Code Integration

[Mark S. <mar...@gm...>]

I have been working this weekend to bring my collection of various
classes into my copy of Rails under two sub-packages
'rails.ui.swing.revenucenters' and 'rails.ui.swing.tiles'. I have been
updating to get them to compile, and use the 'Tag' class to load data
from data files. I expect that I have about 3-4 more classes to go
before I can actually draw the Tile Tray properly.

I was looking at the current copies of 'Company', 'PublicCompany',
'PrivateCompany' and I would like to ask another question.

I see a Company Class hierarchy as follows:

public class Company;

public class PrivateCompany extends Company; // A Company that has no
train, no tokens, and no tile-laying capability

public class TrainCompany extends Company; // A Company that can hold
one or more trains and can lay track

public class CoalCompany extends TrainCompany; // A TrainCompany that
has no Tokens (1837)

public class TokenCompany extends TrainCompany; // A TrainCompany that
has one or more Tokens

public class MinorCompany extends TokenCompany; // A TokenCompany that
is a Minor company with Certificates, but has a fixed share price

public class ShareCompany extends TokenCompany; // A TokenCompany that
is a Major company with Certificates that has flexible price based on
the Market

This could be extended to a SystemCompany that contains two
ShareCompanies. (1832)

 Does a structure like this make sense to you folks?

Mark

Re: [Rails-devel] Status of Tile & Map Code Integration

[brett l. <wak...@gm...>]

On Sun, Nov 9, 2008 at 12:50 PM, Mark Smith <mar...@gm...> wrote:
> I have been working this weekend to bring my collection of various
> classes into my copy of Rails under two sub-packages
> 'rails.ui.swing.revenucenters' and 'rails.ui.swing.tiles'. I have been
> updating to get them to compile, and use the 'Tag' class to load data
> from data files. I expect that I have about 3-4 more classes to go
> before I can actually draw the Tile Tray properly.
>
> Mark
>

Revenue should have an "e" at the end of it. :-)


---Brett.

Re: [Rails-devel] Status of Tile & Map Code Integration

[Mark S. <mar...@gm...>]

Yes, of course it does. I have it correct in the code base. I made a
typo in the e-mail.

On Sun, Nov 9, 2008 at 4:42 PM, brett lentz <wak...@gm...> wrote:
> On Sun, Nov 9, 2008 at 12:50 PM, Mark Smith <mar...@gm...> wrote:
>> I have been working this weekend to bring my collection of various
>> classes into my copy of Rails under two sub-packages
>> 'rails.ui.swing.revenucenters' and 'rails.ui.swing.tiles'. I have been
>> updating to get them to compile, and use the 'Tag' class to load data
>> from data files. I expect that I have about 3-4 more classes to go
>> before I can actually draw the Tile Tray properly.
>>
>> Mark
>>
>
> Revenue should have an "e" at the end of it. :-)
>
>
> ---Brett.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Status of Tile & Map Code Integration

[John A. T. <ja...@ja...>]

Mark Smith wrote:
> I was looking at the current copies of 'Company', 'PublicCompany',
> 'PrivateCompany' and I would like to ask another question.
>
> I see a Company Class hierarchy as follows:
>
> public class Company;
>
> public class PrivateCompany extends Company; // A Company that has no
> train, no tokens, and no tile-laying capability
>
> public class TrainCompany extends Company; // A Company that can hold
> one or more trains and can lay track
>
> public class CoalCompany extends TrainCompany; // A TrainCompany that
> has no Tokens (1837)
>
> public class TokenCompany extends TrainCompany; // A TrainCompany that
> has one or more Tokens
>
> public class MinorCompany extends TokenCompany; // A TokenCompany that
> is a Minor company with Certificates, but has a fixed share price
>
> public class ShareCompany extends TokenCompany; // A TokenCompany that
> is a Major company with Certificates that has flexible price based on
> the Market
>
> This could be extended to a SystemCompany that contains two
> ShareCompanies. (1832)
>
>  Does a structure like this make sense to you folks?
>   
There are so many variations on these in different games, I don't think 
it makes sense to codify the capabilities in the class hierarchy.  For 
example, some minor companies do have stock prices, and some Coal 
companies do have tokens (1824).  I think it is better to have a general 
Company that gets flags at creation time, and when it is created to fill 
a particular role those flags are set appropriately according to the 
game.  You also have to consider company transformations during the 
game, and it seems easiest if it is just one company and you change the 
capabilities when it transforms.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Status of Tile & Map Code Integration

[Mark S. <mar...@gm...>]

Possibly my branches of a CoalCompany, and a MinorCompany are not
required, given that some games (like 1824 allow a Coal Company to
have Tokens, and 1837 provide no tokens to a Coal Company), and a
Minor Company sometimes has a fixed-price, and sometimes a variable
price. I just hate huge classes that distinguish based on flags. I do
see that in the case of 1841 a company can start as a Minor or a Major
Company. In this example, I would probably just keep these both as a
ShareCompany, with a type flag set at creation time.

With regards to transformations, examples being:
1.  Minor Companies in 1824, 1835, 1837 merge to a Share Company,
2. 1856 where Share Companies in debt merge to the CGR,
3. Coal Companies in 1824 and 1837 are exchanged to other company shares
4. 1832 two major companies merge to a System

I am sure there are more variations to this. I do see each of these
transformations as more of an exchange of shares (except for the 1832
System creation). Trying to simply change the capabilities when it
transforms is I feel the wrong approach. It makes an undo that much
harder to accomplish. Besides, the exchanges don't all happen at the
same time (Coal Company Certificate exchange at the owner's
discretion, or Phase change requirement).

When I came up with my hierarchy I was primarily focused on the games
I currently own (1829, 1830, 1835, 1837, 1853, 1856, 1870). And since
then many more sprang up. I do still feel building a basic hierarchy
for companies makes sense. It allows separation of functionality. and
allows the class hierarchy enforce some of the game mechanics (a
company that is just a Train Company, cannot manipulate tokens, and if
a Company is a Token Company, but not a Share Company cannot have
certificates that have variable price). But I would be interested in
what Brett & Erik have to say on the subject. I am sure they have
discussed this in the past.

Re: [Rails-devel] Status of Tile & Map Code Integration

[John A. T. <ja...@ja...>]

Mark Smith wrote:
> When I came up with my hierarchy I was primarily focused on the games
> I currently own (1829, 1830, 1835, 1837, 1853, 1856, 1870). And since
> then many more sprang up. I do still feel building a basic hierarchy
> for companies makes sense. It allows separation of functionality. and
> allows the class hierarchy enforce some of the game mechanics (a
> company that is just a Train Company, cannot manipulate tokens, and if
> a Company is a Token Company, but not a Share Company cannot have
> certificates that have variable price). But I would be interested in
> what Brett & Erik have to say on the subject. I am sure they have
> discussed this in the past.
>   
The problem is there are a large number of variations and more will be 
added over time.  Assume you have n different criteria you want to 
encode in the class hierarchy (exists on the map, has tokens, has a 
share price, may merge, etc).  If you encode all possibilities into the 
hierarchy, you wind up with n^m classes, most of which are very 
similar.  If instead you expose these different functions into separate 
classes and have the company delegate to them depending on what form it 
currently has, you have only n*m classes with no code duplication.

Again think of the idea of Rails being to core code to implement any 
game and the per-game files would contain only unique code needed for 
that game.  If a new game requires a new combination of these features 
in a company, the only option would be to duplicate lots of in-Rails 
code in the game-specific classes, which worsens the maintenance burden 
especially when they may have separate maintainers.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Status of Tile & Map Code Integration

[Brett L. <wak...@gm...>]

On Mon, 2008-11-10 at 23:09 +0100, Erik Vos wrote:
> I completely agree with John. Enforcing a particular hierarchical order in
> which features appear would be too rigid. 
> 
> This could be loosened by creating interfaces like HasShares, HasTokens etc,
> which dedicated (perhaps game-dependent) company classes could implement,
> but that would lead to even more class (+interface) files.
> 
> Other considerations:
> 1. Coding is easier the way it is: you only need tests like hasSharePrice()
> etc. Your way you will get a lot of instanceof's + casts + separate
> variables for the casted subtypes, to handle all the differences in (for
> instance) OperatingRound.
> 
> 2. We have enough classes as it is. I'm only in favour of creating new ones
> if there is a real need for it, which I don't see in this case. I don't want
> to spend too much time and energy in remembering small differences between
> similar classes.
> Systems are the only special types for which I see a need for a new class.
> And maybe the 1841 concessions (but these are more like privates). 
> 

I agree with your basic idea. I don't want our code to mimic the Java
API, with it's numerous varieties of similar containers (List, Array,
ArrayList, Vector, Map, HashMap, etc). 

However, I disagree with the implication that we have "enough" classes.
There is no empiric measurement we can take, no way of calculating an
exact number of classes that are "enough".

If there's a better way to implement something, it shouldn't matter how
many additional classes it requires. What's important is the benefits
brought to the code in terms of maintenance, scaling, and allowing us
humans to clearly understand what the code is doing.

If that means we reorganize things into a larger number of class files,
so be it.

> 3. Yes, PublicCompany is a large class. I'm sure there are some redundancies
> and methods that belong somewhere else (similar to the redundant method in
> Tile that we have spotted recently). But in handling company objects in
> OperatingRound etc., the similarities between the various types look more
> important to me than the differences.

> On transformations: critical to me is whether or not the company name
> changes. If so, it is a new company and shares are exchanged. If not (for
> instance, when a minor or 5-share company transforms to a major or 10-share
> company, as in 1826 and several other games), it remains the same company,
> and shares are moved from "unavailable" to whereever the new shares are to
> be put, and the percentage per share is changed (e.g. from 20 to 10).
> 
> Erik.


---Brett.

> 
> 
> > -----Original Message-----
> > From: John A. Tamplin [mailto:ja...@ja...] 
> > Sent: Monday 10 November 2008 07:45
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Status of Tile & Map Code Integration
> > 
> > Mark Smith wrote:
> > > When I came up with my hierarchy I was primarily focused on 
> > the games
> > > I currently own (1829, 1830, 1835, 1837, 1853, 1856, 1870). 
> > And since
> > > then many more sprang up. I do still feel building a basic hierarchy
> > > for companies makes sense. It allows separation of 
> > functionality. and
> > > allows the class hierarchy enforce some of the game mechanics (a
> > > company that is just a Train Company, cannot manipulate 
> > tokens, and if
> > > a Company is a Token Company, but not a Share Company cannot have
> > > certificates that have variable price). But I would be interested in
> > > what Brett & Erik have to say on the subject. I am sure they have
> > > discussed this in the past.
> > >   
> > The problem is there are a large number of variations and 
> > more will be 
> > added over time.  Assume you have n different criteria you want to 
> > encode in the class hierarchy (exists on the map, has tokens, has a 
> > share price, may merge, etc).  If you encode all 
> > possibilities into the 
> > hierarchy, you wind up with n^m classes, most of which are very 
> > similar.  If instead you expose these different functions 
> > into separate 
> > classes and have the company delegate to them depending on 
> > what form it 
> > currently has, you have only n*m classes with no code duplication.
> > 
> > Again think of the idea of Rails being to core code to implement any 
> > game and the per-game files would contain only unique code needed for 
> > that game.  If a new game requires a new combination of these 
> > features 
> > in a company, the only option would be to duplicate lots of in-Rails 
> > code in the game-specific classes, which worsens the 
> > maintenance burden 
> > especially when they may have separate maintainers.
> > 
> > --
> > John A. Tamplin					ja...@ja...
> > 770/436-5387 HOME				4116 Manson Ave
> >                 		 		Smyrna, GA  30082-3723
> > 
> > 
> > --------------------------------------------------------------
> > -----------
> > This SF.Net email is sponsored by the Moblin Your Move 
> > Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & 
> > win great prizes
> > Grand prize is a trip for two to an Open Source event 
> > anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
---Brett.

The graveyards are full of indispensable men.
		-- Charles de Gaulle

Re: [Rails-devel] Status of Tile & Map Code Integration

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

I completely agree with John. Enforcing a particular hierarchical order in
which features appear would be too rigid. 

This could be loosened by creating interfaces like HasShares, HasTokens etc,
which dedicated (perhaps game-dependent) company classes could implement,
but that would lead to even more class (+interface) files.

Other considerations:
1. Coding is easier the way it is: you only need tests like hasSharePrice()
etc. Your way you will get a lot of instanceof's + casts + separate
variables for the casted subtypes, to handle all the differences in (for
instance) OperatingRound.

2. We have enough classes as it is. I'm only in favour of creating new ones
if there is a real need for it, which I don't see in this case. I don't want
to spend too much time and energy in remembering small differences between
similar classes.
Systems are the only special types for which I see a need for a new class.
And maybe the 1841 concessions (but these are more like privates). 

3. Yes, PublicCompany is a large class. I'm sure there are some redundancies
and methods that belong somewhere else (similar to the redundant method in
Tile that we have spotted recently). But in handling company objects in
OperatingRound etc., the similarities between the various types look more
important to me than the differences.

On transformations: critical to me is whether or not the company name
changes. If so, it is a new company and shares are exchanged. If not (for
instance, when a minor or 5-share company transforms to a major or 10-share
company, as in 1826 and several other games), it remains the same company,
and shares are moved from "unavailable" to whereever the new shares are to
be put, and the percentage per share is changed (e.g. from 20 to 10).

Erik.


> -----Original Message-----
> From: John A. Tamplin [mailto:ja...@ja...] 
> Sent: Monday 10 November 2008 07:45
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Status of Tile & Map Code Integration
> 
> Mark Smith wrote:
> > When I came up with my hierarchy I was primarily focused on 
> the games
> > I currently own (1829, 1830, 1835, 1837, 1853, 1856, 1870). 
> And since
> > then many more sprang up. I do still feel building a basic hierarchy
> > for companies makes sense. It allows separation of 
> functionality. and
> > allows the class hierarchy enforce some of the game mechanics (a
> > company that is just a Train Company, cannot manipulate 
> tokens, and if
> > a Company is a Token Company, but not a Share Company cannot have
> > certificates that have variable price). But I would be interested in
> > what Brett & Erik have to say on the subject. I am sure they have
> > discussed this in the past.
> >   
> The problem is there are a large number of variations and 
> more will be 
> added over time.  Assume you have n different criteria you want to 
> encode in the class hierarchy (exists on the map, has tokens, has a 
> share price, may merge, etc).  If you encode all 
> possibilities into the 
> hierarchy, you wind up with n^m classes, most of which are very 
> similar.  If instead you expose these different functions 
> into separate 
> classes and have the company delegate to them depending on 
> what form it 
> currently has, you have only n*m classes with no code duplication.
> 
> Again think of the idea of Rails being to core code to implement any 
> game and the per-game files would contain only unique code needed for 
> that game.  If a new game requires a new combination of these 
> features 
> in a company, the only option would be to duplicate lots of in-Rails 
> code in the game-specific classes, which worsens the 
> maintenance burden 
> especially when they may have separate maintainers.
> 
> --
> John A. Tamplin					ja...@ja...
> 770/436-5387 HOME				4116 Manson Ave
>                 		 		Smyrna, GA  30082-3723
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

Re: [Rails-devel] Status of Tile & Map Code Integration

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

> However, I disagree with the implication that we have 
> "enough" classes.
> There is no empiric measurement we can take, no way of calculating an
> exact number of classes that are "enough".
> 
> If there's a better way to implement something, it shouldn't 
> matter how
> many additional classes it requires. What's important is the benefits
> brought to the code in terms of maintenance, scaling, and allowing us
> humans to clearly understand what the code is doing.
> 
> If that means we reorganize things into a larger number of 
> class files,
> so be it.

Of course. I only meant to avoid multiplying entities without necessity (if
I may misuse Occam this way).
Erik.

Re: [Rails-devel] Status of Tile & Map Code Integration

[Mark S. <mar...@gm...>]

OK Given that Brett and Erik are both in agreement on this, I will
concede the point. I am not here to make waves. I hope to be here to
help contribute to the development of the project.