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