rails-devel — List for discussion of Rails development

Re: [Rails-devel] [18xx] Rails 1.0.6 has been released.

[JDL <jam...@gm...>]

On Mon, Dec 22, 2008 at 7:21 AM, brett lentz <wak...@gm...> wrote:
> I'm proud to announce that we've got a shiny new release of Rails, the
> Java 18xx client. This release is a bug-fix release, and includes some
> changes under the hood that will help prepare for improvements and
> additional playable games in the future.
>
> I'd like to take this opportunity to thank Erik Vos, and newcomer Mark
> Smith for their hard work. Thanks also goes out to Freek Dijkstra and
> Jonathan Ferro for their patches. Their efforts made this release
> possible.
>
> As usual, you can get your very own copy of this new release at
> http://rails.sourceforge.net/

First of all, thank you for all the hard work that's gone into this.

Has route calculation been added, or is it on the radar?  I used to
have an Eclipse project set up to peruse the Rails source code, but
it's been a year since I dug through it, so I'm quite out of the loop
now.

-- James

Re: [Rails-devel] Rails 1.0.6 has been released.

[Chris S. <chr...@gm...>]

Thanks for doing this.  After the holidays, I plan to start a couple
of new pbem games to kick the tires and give it a whirl.  I'll report
back here any problems or successes we have with it.

--
Chris

Please consider the environment before printing this e-mail.




On Mon, Dec 22, 2008 at 5:21 AM, brett lentz <wak...@gm...> wrote:
> I'm proud to announce that we've got a shiny new release of Rails, the
> Java 18xx client. This release is a bug-fix release, and includes some
> changes under the hood that will help prepare for improvements and
> additional playable games in the future.
>
> I'd like to take this opportunity to thank Erik Vos, and newcomer Mark
> Smith for their hard work. Thanks also goes out to Freek Dijkstra and
> Jonathan Ferro for their patches. Their efforts made this release
> possible.
>
> As usual, you can get your very own copy of this new release at
> http://rails.sourceforge.net/
>
> Any bugs, problems, or suggestions you may have can be sent to
> rai...@li...
>
>
> ---Brett.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Rails 1.0.6 has been released.

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

I'm proud to announce that we've got a shiny new release of Rails, the
Java 18xx client. This release is a bug-fix release, and includes some
changes under the hood that will help prepare for improvements and
additional playable games in the future.

I'd like to take this opportunity to thank Erik Vos, and newcomer Mark
Smith for their hard work. Thanks also goes out to Freek Dijkstra and
Jonathan Ferro for their patches. Their efforts made this release
possible.

As usual, you can get your very own copy of this new release at
http://rails.sourceforge.net/

Any bugs, problems, or suggestions you may have can be sent to
rai...@li...


---Brett.

Re: [Rails-devel] Release

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

Yup.  We had planned on the 21st, which is tomorrow.

---Brett.

On Sat, Dec 20, 2008 at 7:08 AM, Erik Vos <eri...@hc...> wrote:
> Brett,
>
> Are you going to bring out the next release one of these days?
>
> I'm upholding any further changes until it is out.
>
> Regards,
> Erik
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Release

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

Brett,

Are you going to bring out the next release one of these days?

I'm upholding any further changes until it is out.

Regards,
Erik

[Rails-devel] 18EU

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

Yesterday I thought I had found a bug in StockRound_18EU, which I fixed. 
However, on rereading the rules today, it turns out that the original code
was correct, so I reverted the change.

The issue is whether or not it is allowed to merger a minor into a
corporation that has already operated, before the Final Minor Exchange
Round. I thought it is (we may have always played it that way), but in fact
it is not (which rule I had implemented correctly). Memory did not serve me
this time.

Erik

[Rails-devel] 18EU fixes and cleanups

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

I have found and fixed a few bugs in 18EU, localised two hardcoded texts in
ORWindow and ReportWindow, and further applied some annotations (to suppress
innocent warnings) and cleanups.

I believe that we are about ready for the release.

Things I want to look at after the release are:
- another look at Round initialisation, partly as a follow-up to my
discussions with Mark and Jean, and partly because I think there might be
more to put into the generic round initialisation code.
- I have "discovered" the Java 5.0 varargs (about time, you might say) and
have already found it to work fine with LocalText.getText() (where the
underlying library formatting method also uses varargs). This would allow us
to get rid of the "String[]{}" bit when there is more that one string value
to fill in.
- 1856 continued.

Erik 

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

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

Hi Jean,
 
I'm afraid the word "choice" is not really applicable, as I was only vaguely
aware of the second possibility. 
I have looked a bit around, but I have trouble finding a good usage example.
Do you know how to rewrite GameManager.createRound() using reflection, in
Java 5.0 style (with generics), passing gameManager to a Round subclass
constructor taking this single object?
 
If we can get this done, I'm happy to give in to Mark.
 
Thanks for your best wishes, and perhaps it'll even get better if you
contribute some of your wisdom....
 
Erik.


  _____  

From: Jean Michalski (Europe) [mailto:Jea...@eu...] 
Sent: Monday 08 December 2008 08:02
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Another Bug I have found, and worked out a fix
for


Hi Erik,
 
Thank you for the answer, it becomes more clear.  So in short, it is an
implementation choice of yours to use java.lang.Class.newInstance() instead
of java.lang.reflect.Constructor.newInstance(Object[] initargs).
 
Kind regards, and best wishes in your endeavours,
 
Jean.


  _____  

From: Erik Vos [mailto:eri...@hc...] 
Sent: 08 December 2008 00:22
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] Another Bug I have found, and worked out a fix
for


Hi Jean,
 
The point is, that several class names are configurable. For instance, the
default operating round class is OperatingRound, but several games use more
specialized subclasses, with names like OperatingRound_18xx. Examples are
18AL and 18EU; see the <OperatingRound> tags in the Games.xml files of these
games.
 
These classes (and most other Round subclasses) are dynamically instantiated
in method createRound() of class GameManager, by calling the newInstance()
method of a Class object for the particular class to be created. The
newInstance() method requires a parameterless constructor, like
OperatingRound(). So we can only use such constructors; constructors that
take parameters are useless for these classes. 
 
(I think there are ways to create newInstance methods that take parameters
as well, but I didn't find it worth while to sort out how to jump through
those hoops, as we already had a simple solution).
 
Parameterless constructors can obviously only initialize fixed/default
values, nothing that is variable (except through calling class methods, but
we want to get away from class methods). That means that all further
initialization must be done by calling a non-constructor method; in this
case setGameManager().
 
I hope this helps.
Erik.


  _____  

From: Jean Michalski (Europe) [mailto:Jea...@eu...] 
Sent: Sunday 07 December 2008 09:46
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Another Bug I have found, and worked out a fix
for


Hi Mark, Erik, everyone,
 
Just a small note to say I have followed the discussion, and without any
pretention to say I understand the gritty details, Erik says that the
classes in question are being instantiated "dynamically", e.g. in a way such
that constructors would be inappropriate.  So he says he would be happier to
leave the empty constructors and use the setGameManager() or any other
configuration method.
 
Erik, would you be so kind as pointing out very pragmatically to one
specific such case?  I think it might enlighten at least myself on the way
the architecture has been thought out and built.  This would have all of us
looking into the same direction (or question the direction, but this would
certainly not come from me).
 
Thank you,
 
Jean (John in French) Michalski


  _____  

From: Mark Smith [mailto:mar...@gm...] 
Sent: 05 December 2008 23:43
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Another Bug I have found, and worked out a fix
for


OK, if you feel that parametrized constructors is a step backwards, I will
comply with your request. I don't agree, but I won't argue about it any
more.

Mark

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

[Jean M. (Europe) <Jea...@eu...>]

Hi Erik,
 
Thank you for the answer, it becomes more clear.  So in short, it is an
implementation choice of yours to use java.lang.Class.newInstance()
instead of java.lang.reflect.Constructor.newInstance(Object[] initargs).
 
Kind regards, and best wishes in your endeavours,
 
Jean.


________________________________

	From: Erik Vos [mailto:eri...@hc...] 
	Sent: 08 December 2008 00:22
	To: 'Development list for Rails: an 18xx game'
	Subject: Re: [Rails-devel] Another Bug I have found, and worked
out a fix for
	
	
	Hi Jean,
	 
	The point is, that several class names are configurable. For
instance, the default operating round class is OperatingRound, but
several games use more specialized subclasses, with names like
OperatingRound_18xx. Examples are 18AL and 18EU; see the
<OperatingRound> tags in the Games.xml files of these games.
	 
	These classes (and most other Round subclasses) are dynamically
instantiated in method createRound() of class GameManager, by calling
the newInstance() method of a Class object for the particular class to
be created. The newInstance() method requires a parameterless
constructor, like OperatingRound(). So we can only use such
constructors; constructors that take parameters are useless for these
classes. 
	 
	(I think there are ways to create newInstance methods that take
parameters as well, but I didn't find it worth while to sort out how to
jump through those hoops, as we already had a simple solution).
	 
	Parameterless constructors can obviously only initialize
fixed/default values, nothing that is variable (except through calling
class methods, but we want to get away from class methods). That means
that all further initialization must be done by calling a
non-constructor method; in this case setGameManager().
	 
	I hope this helps.
	Erik.


________________________________

		From: Jean Michalski (Europe)
[mailto:Jea...@eu...] 
		Sent: Sunday 07 December 2008 09:46
		To: Development list for Rails: an 18xx game
		Subject: Re: [Rails-devel] Another Bug I have found, and
worked out a fix for
		
		
		Hi Mark, Erik, everyone,
		 
		Just a small note to say I have followed the discussion,
and without any pretention to say I understand the gritty details, Erik
says that the classes in question are being instantiated "dynamically",
e.g. in a way such that constructors would be inappropriate.  So he says
he would be happier to leave the empty constructors and use the
setGameManager() or any other configuration method.
		 
		Erik, would you be so kind as pointing out very
pragmatically to one specific such case?  I think it might enlighten at
least myself on the way the architecture has been thought out and built.
This would have all of us looking into the same direction (or question
the direction, but this would certainly not come from me).
		 
		Thank you,
		 
		Jean (John in French) Michalski


________________________________

			From: Mark Smith [mailto:mar...@gm...]

			Sent: 05 December 2008 23:43
			To: Development list for Rails: an 18xx game
			Subject: Re: [Rails-devel] Another Bug I have
found, and worked out a fix for
			
			
			OK, if you feel that parametrized constructors
is a step backwards, I will comply with your request. I don't agree, but
I won't argue about it any more.
			
			Mark
			

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

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

Hi Jean,
 
The point is, that several class names are configurable. For instance, the
default operating round class is OperatingRound, but several games use more
specialized subclasses, with names like OperatingRound_18xx. Examples are
18AL and 18EU; see the <OperatingRound> tags in the Games.xml files of these
games.
 
These classes (and most other Round subclasses) are dynamically instantiated
in method createRound() of class GameManager, by calling the newInstance()
method of a Class object for the particular class to be created. The
newInstance() method requires a parameterless constructor, like
OperatingRound(). So we can only use such constructors; constructors that
take parameters are useless for these classes. 
 
(I think there are ways to create newInstance methods that take parameters
as well, but I didn't find it worth while to sort out how to jump through
those hoops, as we already had a simple solution).
 
Parameterless constructors can obviously only initialize fixed/default
values, nothing that is variable (except through calling class methods, but
we want to get away from class methods). That means that all further
initialization must be done by calling a non-constructor method; in this
case setGameManager().
 
I hope this helps.
Erik.


  _____  

From: Jean Michalski (Europe) [mailto:Jea...@eu...] 
Sent: Sunday 07 December 2008 09:46
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Another Bug I have found, and worked out a fix
for


Hi Mark, Erik, everyone,
 
Just a small note to say I have followed the discussion, and without any
pretention to say I understand the gritty details, Erik says that the
classes in question are being instantiated "dynamically", e.g. in a way such
that constructors would be inappropriate.  So he says he would be happier to
leave the empty constructors and use the setGameManager() or any other
configuration method.
 
Erik, would you be so kind as pointing out very pragmatically to one
specific such case?  I think it might enlighten at least myself on the way
the architecture has been thought out and built.  This would have all of us
looking into the same direction (or question the direction, but this would
certainly not come from me).
 
Thank you,
 
Jean (John in French) Michalski


  _____  

From: Mark Smith [mailto:mar...@gm...] 
Sent: 05 December 2008 23:43
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Another Bug I have found, and worked out a fix
for


OK, if you feel that parametrized constructors is a step backwards, I will
comply with your request. I don't agree, but I won't argue about it any
more.

Mark

Re: [Rails-devel] Status of "bug" 1945690

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

On Sun, Dec 7, 2008 at 11:39 AM, Erik Vos <eri...@hc...> wrote:
> I have looked the reported tracked "bug" 1945690 and tried what could be
> done about it.
> Here are the contents after the update I have just made:
>
> [Opened by anonymous:]
> When 5 companies floated in 1851, action buttons are off the screen in
> normal size
>
> [Comment by krazick:]
> This sort of problem will most likely affect more than just 1851, it all
> depends on how many companies are in the game. The List of Companies on the
> Map Window probably should be a scrollable list... and maybe the Action
> Buttons should appear Above the list in a non-scrollable section.
>
> [Just added by me:]
> This problem is at least partly fixed by making the window remember its
> position and height, after it has been repositioned/resized manually (see
> bug fix 1945695).
>
> I have tried to split the screen, so that the division between upper and
> lower part can be manually moved. This allows the lower part to be made
> scrollable. That all works, but I could not find a satisfactory way to set
> the initial pane division so that the result looks good for all games and
> game phases. The result is often ugly, so I have undone all of this.
>
> Not sure if it is worth while to keep this "bug" open; in any case, it is
> unlikely that I will spend any more effort on it.
> [End of bug report]
>
> Since the original Map and OR windows have been merged a few years ago, I
> have been afraid that we would run into such trouble, and indeed I have been
> frequently annoyed by the consequences of this window often being much
> higher than the available screen space. Last week I have made the window
> remember its height, so that it would no longer scroll off the screen at the
> start of each new OR after it has been manually set to a reasonable size.
>
> For me, this has removed most of the trouble I had with the OR window.  Any
> other views?
>
> Erik
>

I haven't tested your changes yet.  I believe that the solution to
this is figuring out what the ideal size for each element in the OR
Window, and having that be used to calculate the minimum size of the
whole window, then using that minimum as the initial window size that
we use.  However, one prerequisite for doing this is having a map that
knows what size it's supposed to be. I don't think that we can improve
the rest of the OR Window much more than we already have until we've
improved on drawing the map.

---Brett.

[Rails-devel] Status of "bug" 1945690

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

I have looked the reported tracked "bug" 1945690 and tried what could be
done about it.
Here are the contents after the update I have just made:

[Opened by anonymous:]
When 5 companies floated in 1851, action buttons are off the screen in
normal size

[Comment by krazick:]
This sort of problem will most likely affect more than just 1851, it all
depends on how many companies are in the game. The List of Companies on the
Map Window probably should be a scrollable list... and maybe the Action
Buttons should appear Above the list in a non-scrollable section.

[Just added by me:]
This problem is at least partly fixed by making the window remember its
position and height, after it has been repositioned/resized manually (see
bug fix 1945695).

I have tried to split the screen, so that the division between upper and
lower part can be manually moved. This allows the lower part to be made
scrollable. That all works, but I could not find a satisfactory way to set
the initial pane division so that the result looks good for all games and
game phases. The result is often ugly, so I have undone all of this. 

Not sure if it is worth while to keep this "bug" open; in any case, it is
unlikely that I will spend any more effort on it.
[End of bug report]

Since the original Map and OR windows have been merged a few years ago, I
have been afraid that we would run into such trouble, and indeed I have been
frequently annoyed by the consequences of this window often being much
higher than the available screen space. Last week I have made the window
remember its height, so that it would no longer scroll off the screen at the
start of each new OR after it has been manually set to a reasonable size. 

For me, this has removed most of the trouble I had with the OR window.  Any
other views?

Erik

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

[Jean M. (Europe) <Jea...@eu...>]

Hi Mark, Erik, everyone,
 
Just a small note to say I have followed the discussion, and without any
pretention to say I understand the gritty details, Erik says that the
classes in question are being instantiated "dynamically", e.g. in a way
such that constructors would be inappropriate.  So he says he would be
happier to leave the empty constructors and use the setGameManager() or
any other configuration method.
 
Erik, would you be so kind as pointing out very pragmatically to one
specific such case?  I think it might enlighten at least myself on the
way the architecture has been thought out and built.  This would have
all of us looking into the same direction (or question the direction,
but this would certainly not come from me).
 
Thank you,
 
Jean (John in French) Michalski


________________________________

	From: Mark Smith [mailto:mar...@gm...] 
	Sent: 05 December 2008 23:43
	To: Development list for Rails: an 18xx game
	Subject: Re: [Rails-devel] Another Bug I have found, and worked
out a fix for
	
	
	OK, if you feel that parametrized constructors is a step
backwards, I will comply with your request. I don't agree, but I won't
argue about it any more.
	
	Mark
	

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

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

OK, if you feel that parametrized constructors is a step backwards, I will
comply with your request. I don't agree, but I won't argue about it any
more.

Mark

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

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

1. Adding constructors with a GameManager parameter is pointless, as all
Start/Stock/OperatingRound instances are (or should be) created with
newInstance(), which uses the no-parameter constructors. That is why Round
has a setGameManager() method, to be called after creating of any round
(mostly from GameManager). Via GameManager this method (indirectly) imports
references to all static objects into the rounds (and those objects that
aren't included yet will be in the future). 

The reason I add the constructors with the GameManager parameter is to allow
the sub-class constructors, like 'ShareSellingRound' (it already had a
constructor with parameters) can call the super-class constructor with the
GameManager parameter and let IT worry about doing the initialization. Yes,
they could call setGameManager, (as you point out below). But the purpose of
a constructor is to INITIALIZE Stuff. That is their ONLY Purpose. If you
hate constructors, which it appears you do, then you can toss my
constructors, and call the appropriate initialization routines.
 


2. The special classes like ShareSellingRound are currently created in a
different way (that may change in the future, should we ever need
game-specific versions). These classes can equally well call
setGameManager(gameManager), rather that super(gameManager), making these
one-parameter constructors completely unncecessary. 

Indeed constructors are to initialize stuff, and I have nothing against
that, but you seem to turn it around by implying that initializations should
always (if anyhow possible) be done inside constructors. You seem to have
missed the point that I was trying to make above, that many classes can only
be initialized after instantiation (by a method like setGameManager) because
these classes are dynamically instantiated, which requires a constructor
that does not take any parameters (and therefore cannot initialize any
non-default values). 
 
See how most Round classes are instantiated in GameManager.createRound().
The number of classes that is created this way increases every time we find
that some type of class needs be dynamically created. So, as soon as we
discover that the choice of ShareSellingRound and/or TreasuryShareRound need
to become configurable, your reasoning falls apart for these classes, as
we'll then have to separate initialization from instantiation for these
classes as well.
 
So, as the architecture of this gaming system has developed over the past
years, and is still developing, your desire to add initializing (and hence
parametrized) constructors is a step backwards into a dead end.
 
This is my main point, and (thinking again about it) it's not a matter of
taste. The rest is.

3. In Round(), setGameManager(null) is a no-op, why adding it?


I added the call to setGameManager (null) in Round to allow for any other
initialization that setGameManager may want to do in the future, to keep the
initialization in one place. The current effect of calling setGameManager
with null changes nothing as the routine is currently written. But I hate to
NOT initialize stuff, nor do I like to use default values. If I have code
specifically to set the value to something, I know where it is set. But
again, this is style/taste. I can take it or leave it really.  

 Indeed. I prefer shorthand, you prefer to spell things out. Doesn't really
matter.

4. Again probably a matter of taste. The following three statements are all
equivalent:
 
    StockRound() { super(); }
    StockRound() {}
    <empty>
 
because the compiler is so friendly to add all that is missing. In such
matters I tend to code minimally: leaving out what is automatic or obvious
(in pedantic mode I like to say that I apply Occam's razor; I admit that
existing empty constructors like OperatingRound() had escaped that razor so
far). You seem more inclined to code maximally here, including stuff that
will exist anyway (stating the obvious, as it were). I tend to take "cleaner
code" pretty literally: "less code".



This is again some of my old-school programming training. Don't trust the
compiler to do this sort of work for you. If you specifically state it, and
be clear about it, the compile won't mess it up. By leaving it "empty" you
make an assumption. And the bug I found was based on your assumption that
the initialization always worked. and yet a step was missed.

Java guarantees this compiler behaviour, I see no reason not to trust that.
But if you want these (parameterless) constructors, fine with me.
 
I skip the remaining (minor) points from the previous posts.
 
Erik.
 

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

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

On Thu, Dec 4, 2008 at 3:54 PM, Erik Vos <eri...@hc...> wrote:

>
>       Feel free to look over my constructors...and let me know if I have
> mucked up something or actually made the code cleaner please.
>
> OK, here we go. Much of what I'm going to say is probably a matter of taste
> (or style), and our tastes apparently differ. Nothing wrong with that. But
> I, for me, don't see much improvement.
>
>

Style/Taste of course is a large part of why I was tinkering here. And yes,
different people have different preferences


> 1. Adding constructors with a GameManager parameter is pointless, as all
> Start/Stock/OperatingRound instances are (or should be) created with
> newInstance(), which uses the no-parameter constructors. That is why Round
> has a setGameManager() method, to be called after creating of any round
> (mostly from GameManager). Via GameManager this method (indirectly) imports
> references to all static objects into the rounds (and those objects that
> aren't included yet will be in the future).
>
>

The reason I add the constructors with the GameManager parameter is to allow
the sub-class constructors, like 'ShareSellingRound' (it already had a
constructor with parameters) can call the super-class constructor with the
GameManager parameter and let IT worry about doing the initialization. Yes,
they could call setGameManager, (as you point out below). But the purpose of
a constructor is to INITIALIZE Stuff. That is their ONLY Purpose. If you
hate constructors, which it appears you do, then you can toss my
constructors, and call the appropriate initialization routines.


> 2. The special classes like ShareSellingRound are currently created in a
> different way ( that may change in the future, should we ever need
> game-specific versions). These classes can equally well call
> setGameManager(gameManager), rather that super(gameManager), making these
> one-parameter constructors completely unncecessary.
>
> 3. In Round(), setGameManager(null) is a no-op, why adding it?
>

I added the call to setGameManager (null) in Round to allow for any other
initialization that setGameManager may want to do in the future, to keep the
initialization in one place. The current effect of calling setGameManager
with null changes nothing as the routine is currently written. But I hate to
NOT initialize stuff, nor do I like to use default values. If I have code
specifically to set the value to something, I know where it is set. But
again, this is style/taste. I can take it or leave it really.


>
> 4. Again probably a matter of taste. The following three statements are all
> equivalent:
>
>     StockRound() { super(); }
>     StockRound() {}
>     <empty>
>
> because the compiler is so friendly to add all that is missing. In such
> matters I tend to code minimally: leaving out what is automatic or obvious
> (in pedantic mode I like to say that I apply Occam's razor; I admit that
> existing empty constructors like OperatingRound() had escaped that razor so
> far). You seem more inclined to code maximally here, including stuff
> that will exist anyway (stating the obvious, as it were). I tend to
> take "cleaner code" pretty literally: "less code".
>

This is again some of my old-school programming training. Don't trust the
compiler to do this sort of work for you. If you specifically state it, and
be clear about it, the compile won't mess it up. By leaving it "empty" you
make an assumption. And the bug I found was based on your assumption that
the initialization always worked. and yet a step was missed.


>
>  5. I personally hate these aThis and theThat variable names; YMMV.
>

Here is one of my purely personaly taste items. I tend to write code with
the arguments comming in prefixed with 'a' and local method variable
prefixed with 't' to make it clear within the code where it came from. If
this is something that will get under your skin, then before I add my code
base, I will need to go through it and strip those prefixes out.


>
> 6. I'm no fan of Javadoc comments like "Constructor with no parameters,
> call the super Class (Round's) Constructor with no parameters". Javadocs
> should describe a method's purpose or usage rather than its contents.
>

Since this was my first true attempt to write Javadocs, I was taking a
guess. I will be flexible here, and see if I can do better in the future.


>
> On the positive side, your version of setGameManager() is better, and it
> has also become clear that ShareSellingRound and TreasuryShareRound should
> call this method rather than doing their own settings.
>
>

At least I did something that you don't outright hate. :-) But the
setGameManager I did not alter in any way (the one in Round.java). I simply
had the constructors call it properly.

It all gets back to my initial point of which level of the class hierarchy
should initialize what parts.

I hope I haven't disappointed you too much - it's not my intention to put
> you off, but I do think that you have added unnecessary code.
>
>

Disappointed? - No. as you stated, it is mostly Style/Taste. You and Brett
have been engineering most of this product so far, so my comming in needs to
be balanced with your coding style. I cannot be the maverick who comes in
and shoots holes in everything everywhere just because I carry a shotgun,
and think I know how to use it.

I do feel I have much to contribute still.

But be warned, I will be picking on other aspects of the implementation,
here and there. There is some items that I have seen that set my teeth on
edge... (for example 'counting the number of passes' to determine if a stock
round is over)


> Erik.
>
>
>
>
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
>
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

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

      Feel free to look over my constructors...and let me know if I have
mucked up something or actually made the code cleaner please.

OK, here we go. Much of what I'm going to say is probably a matter of taste
(or style), and our tastes apparently differ. Nothing wrong with that. But
I, for me, don't see much improvement.
 
1. Adding constructors with a GameManager parameter is pointless, as all
Start/Stock/OperatingRound instances are (or should be) created with
newInstance(), which uses the no-parameter constructors. That is why Round
has a setGameManager() method, to be called after creating of any round
(mostly from GameManager). Via GameManager this method (indirectly) imports
references to all static objects into the rounds (and those objects that
aren't included yet will be in the future). 
 
2. The special classes like ShareSellingRound are currently created in a
different way ( that may change in the future, should we ever need
game-specific versions). These classes can equally well call
setGameManager(gameManager), rather that super(gameManager), making these
one-parameter constructors completely unncecessary.
 
3. In Round(), setGameManager(null) is a no-op, why adding it?
 
4. Again probably a matter of taste. The following three statements are all
equivalent:
 
    StockRound() { super(); }
    StockRound() {}
    <empty>
 
because the compiler is so friendly to add all that is missing. In such
matters I tend to code minimally: leaving out what is automatic or obvious
(in pedantic mode I like to say that I apply Occam's razor; I admit that
existing empty constructors like OperatingRound() had escaped that razor so
far). You seem more inclined to code maximally here, including stuff that
will exist anyway (stating the obvious, as it were). I tend to take "cleaner
code" pretty literally: "less code".
 
5. I personally hate these aThis and theThat variable names; YMMV.
 
6. I'm no fan of Javadoc comments like "Constructor with no parameters, call
the super Class (Round's) Constructor with no parameters". Javadocs should
describe a method's purpose or usage rather than its contents.
 
On the positive side, your version of setGameManager() is better, and it has
also become clear that ShareSellingRound and TreasuryShareRound should call
this method rather than doing their own settings.
 
I hope I haven't disappointed you too much - it's not my intention to put
you off, but I do think that you have added unnecessary code.
 
Erik.
 
 
 

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

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

Alright, due to the oddity of XCode, that I still have not got completely
figured out, I have gotten the nine (9) classes updated and committed with
the new constructors. I had to check them in one at a time and fiddle with
CVS Entries. Dang annoying.

I honestly really like XCode for the development side, but it has very
strange behavior when interacting with CVS on source forge... or I am doing
something really weird that I can't tell.

Feel free to look over my constructors...and let me know if I have mucked up
something or actually made the code cleaner please.

Mark

Re: [Rails-devel] Cleanups

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

OK with these cleanups, I am down to four warnings, just the getLement
items. I can accept them.

Thanks.

On Wed, Dec 3, 2008 at 3:23 PM, Erik Vos <eri...@hc...> wrote:

>  Probably my warning settings are a bit lower than yours...
>
>  I still get about 30 warnings (I had 32 before)... --
>
> getSpecialProperties () in rails.game.RoundI has been deprecated
> percentageOwnedByPlayers() in rails.game.PublicCompanyI has been deprecated
>
>
> Removed (were unused).
>
>         getStatus() in rails.game.action.StartItemAction has been
> deprecated
>
> Undeprecated (there must have been a good reason why I did it, but I don't
> remember).
>
>          getElement() in rails.util.Tag has been deprecated (in
> ConvertTilesXML.java:167 and MakeGameTileSets.java:66,94,102)
>
> Will stay so for a while. Your new map code may make these utilities
> obsolete. I'll wait for that.
>
> Erik.
>
>
>
>
> -------------------------------------------------------------------------
> 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] Another Bug I have found, and worked out a fix for

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

OK. I can accept that.

What I find disturbing is initializing something in the super class by the
sub-class, when it is NOT a special case initialization for the sub-class. I
will get the stuff checked in this evening. With proper Java Docs.

Mark

On Wed, Dec 3, 2008 at 3:32 PM, Erik Vos <eri...@hc...> wrote:

>  Well, I guess I have to wait and see what you come up with. Your standard
> may work for the Rounds, but keep in mind that not all initializations can
> be done in constructors because of sequence issues, which is exactly why
> there are so many empty or missing constructors in the game engine.
>
> Erik.
>
>  ------------------------------
> *From:* Mark Smith [mailto:mar...@gm...]
> *Sent:* Wednesday 03 December 2008 00:52
> *To:* Development list for Rails: an 18xx game
> *Subject:* Re: [Rails-devel] Another Bug I have found, and worked out a
> fix for
>
> Yes, the simple fix is as you state. However, the purpose for sub-classing
> is to use the super-class constructor routines to initialize stuff at that
> superclass level, and use the sub-class constructors to call the super class
> constructor, and then initialize what the sub-class needs. Without doing
> proper constructors, at all levels, you wind up forgetting to initialize
> something (as in this case). It may introduce some extra code in some
> places, but it reduces errors like this one.
>
> Am I not being clear?
>
> I hate messy code, and would much prefer to follow at least a
> pseudo-standard.
>
> I was using "required" and "needed" because when I tried to create just the
> super-class constructor, the compiler complained the sub-class did not have
> the appropriate constructor. So I created those, and cleaned up stuff as I
> saw it needed to be cleaned up.
>
>
>
> On Tue, Dec 2, 2008 at 3:13 PM, Erik Vos <eri...@hc...> wrote:
>
>>   I have adjusted my copies of the various classes to resolve this Null
>> Pointer Exception, by creating constructors for the Round, StockRound,
>> OperatingRound and the sub-classes of StockRound. It does require
>> modifications of all of these for the constructors. A total of 8 classes to
>> update. (the sub-classes of OperatingRound does not require an update. But
>> probably should have constructors created for consistancy's sake.
>>
>> The simple fix would have been to add
>>
>> *    this*.companyManager = gameManager.getCompanyManager();
>>
>> to the ShareSellingRound constructor. That works for me to fix the problem
>> (which I have reproduced). Not sure what you are trying to achieve by adding
>> all these constructors.
>>
>> As for the second suggestion, I have indeed implemented the constructors
>> such that the super-classes do all the initialization that should, and the
>> sub-classes do the initialization they should. In a couple of places I
>> needed to create a constructor that simply called the super class
>> constructor and nothing more.
>>
>> I wonder why you are using worls like "required" and "needed": such
>> default constructors can be omitted.
>>
>> I have noticed that XCode does warn about several classes marked as
>> deprecated (in your comments) that are still being used. But the deprecation
>> comment does not specify what should be used instead. Those might be a
>> better item to clean up then simply adding JAVA Docs.
>>
>> Good point. Thanks.
>>
>> Erik.
>>
>> -------------------------------------------------------------------------
>> 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
>
>

Re: [Rails-devel] Setting Erie home base during green upgrade

[John D. G. <jd...@di...>]

Typo corrected.

>>> John David Galt wrote:
>>>> But when one of those hexes -- or any OO, XX, or similar hex that
>>>> already has at least one token -- gets a tile laid on it, THEN
>>>> whoever lays the tile (NOT necessarily the company owner!) should
>>>> be prompted to choose which station gets which token.

>> Erik Vos wrote:
>>> That is how I have implemented it, but I'm having second thoughts
>>> about that. In fact I had intended to let the president make the 
>>> choice, but I overlooked the possibility that another player might 
>>> update such a OO or XX hex to green. This is rather unlikely,
>>> though, so perhaps I'll leave it as is. The rules are completely
>>> silent about this question.

I agree, for all three games.

>>>> I have always played that if these companies have no home tile
>>>> and don't bother to lay it on their first turn, they give up their
>>>> right to make this choice.

>>> I would rule differently, but I don't know if there is any basis to
>>> settle this dispute. Has there ever be a ruling on this matter?

> John David Galt wrote:
>> Not that I'm aware of.  It was debated a year ago on the 18xx list.

Erik Vos wrote:
> Found, that was in Feb 2007.

>> The main case where it would come up is when someone opens the Erie
>> or THB just before the permanent trains come out, as a source of
>> capital, and doesn't want it to have to buy a train, so he doesn't
>> build it a route.  The other nearby players will want to thwart this
>> tactic by building a route for that company.  If (say) the NYC lays
>> Erie's home OO tile after Erie has had two turns, it seems to me
>> it's against the spirit of the game to then allow Erie to say, "my
>> home station is the one your track doesn't connect to."  Erie had
>> its chance and passed it.

> That makes some sense too.

I should explain this a little better:

I'm reasoning from the general rule (in all 18xx games, I believe) that
if you upgrade a tile where token(s) are already present, and there is
a choice of which city is which, the person making the upgrade chooses.

I believe that in all games except 1835, at the start of each company's
first operating turn, its home token is automatically (and
involuntarily) placed in a city circle on its home hex -- even if the
hex has no tile and the city has no track connected to it.  If this is
true, then the general rule applies when the tile is laid afterward, no
matter who does it.  This, in my view, answers the question for Erie
and THB.

In 1835, most companies' home tokens are placed immediately upon
flotation, during the stock round.  But version 1 of the English rules
made BA an explicit exception to that timing, saying that its home
token is not placed until someone lays a green tile on Ludwigshafen/
Mannheim.  If that is true, then BA's owner will always have his choice
of those two green cities.

But as you say, that exception does not seem to be stated in version 2.
Was that deletion an intentional change, or just carelessness?
Reasonable people will differ.  But if it was an intentional change,
then the general rule applies, just as it does to Erie and THB.

> As said before, I'm not going to change anything now. But I don't
> consider the issue settled.

Me neither.  Perhaps the best answer is to make it a setting that a GM
can change (such as an option in the game definition .xml file).

Re: [Rails-devel] Setting Erie home base during green upgrade

[John D. G. <jd...@di...>]

>>> John David Galt wrote:
>>>> But when one of those hexes -- or any OO, XX, or similar hex that
>>>> already has at least one token -- gets a tile laid on it, THEN
>>>> whoever lays the tile (NOT necessarily the company owner!) should
>>>> be prompted to choose which station gets which token.

>> Erik Vos wrote:
>>> That is how I have implemented it, but I'm having second thoughts
>>> about that. In fact I had intended to let the president make the 
>>> choice, but I overlooked the possibility that another player might 
>>> update such a OO or XX hex to green. This is rather unlikely,
>>> though, so perhaps I'll leave it as is. The rules are completely
>>> silent about this question.

I agree, for all three games.

>>>> I have always played that if these companies have no home tile
>>>> and don't bother to lay it on their first turn, they give up their
>>>> right to make this choice.

>>> I would rule differently, but I don't know if there is any basis to
>>> settle this dispute. Has there ever be a ruling on this matter?

> John David Galt wrote:
>> Not that I'm aware of.  It was debated a year ago on the 18xx list.

Erik Vos wrote:
> Found, that was in Feb 2007.

>> The main case where it would come up is when someone opens the Erie
>> or THB just before the permanent trains come out, as a source of
>> capital, and doesn't want it to have to buy a train, so he doesn't
>> build it a route.  The other nearby players will want to thwart this
>> tactic by building a route for that company.  If (say) the NYC lays
>> Erie's home OO tile after Erie has had two turns, it seems to me
>> it's against the spirit of the game to then allow Erie to say, "my
>> home station is the one your track doesn't connect to."  Erie had
>> its chance and passed it.

> That makes some sense too.

I should explain this a little better:

I'm reasoning from the general rule (in all 18xx games, I believe) that
if you upgrade a tile where token(s) are already present, and there is
a choice of which city is which, the person making the upgrade chooses.

I believe that in all games except 1835, each company's home token is
automatically (and involuntarily) placed in a city circle on its home
hex -- even if the hex has no tile and the city has no track connected
to it.  If this is true, then the general rule applies when the tile is
laid afterward, no matter who does it.  This, in my view, answers the
question for Erie and THB.

In 1835, most companies' home tokens are placed immediately upon
flotation, during the stock round.  But version 1 of the English rules
made BA an explicit exception to that timing, saying that its home
token is not placed until someone lays a green tile on Ludwigshafen/
Mannheim.  If that is true, then BA's owner will always have his choice
of those two green cities.

But as you say, that exception does not seem to be stated in version 2.
Was that deletion an intentional change, or just carelessness?
Reasonable people will differ.  But if it was an intentional change,
then the general rule applies, just as it does to Erie and THB.

> As said before, I'm not going to change anything now. But I don't
> consider the issue settled.

Me neither.  Perhaps the best answer is to make it a setting that a GM
can change (such as an option in the game definition .xml file).

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

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

Well, I guess I have to wait and see what you come up with. Your standard
may work for the Rounds, but keep in mind that not all initializations can
be done in constructors because of sequence issues, which is exactly why
there are so many empty or missing constructors in the game engine.
 
Erik.


  _____  

From: Mark Smith [mailto:mar...@gm...] 
Sent: Wednesday 03 December 2008 00:52
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Another Bug I have found, and worked out a fix
for


Yes, the simple fix is as you state. However, the purpose for sub-classing
is to use the super-class constructor routines to initialize stuff at that
superclass level, and use the sub-class constructors to call the super class
constructor, and then initialize what the sub-class needs. Without doing
proper constructors, at all levels, you wind up forgetting to initialize
something (as in this case). It may introduce some extra code in some
places, but it reduces errors like this one. 

Am I not being clear?

I hate messy code, and would much prefer to follow at least a
pseudo-standard. 

I was using "required" and "needed" because when I tried to create just the
super-class constructor, the compiler complained the sub-class did not have
the appropriate constructor. So I created those, and cleaned up stuff as I
saw it needed to be cleaned up.




On Tue, Dec 2, 2008 at 3:13 PM, Erik Vos <eri...@hc...> wrote:


I have adjusted my copies of the various classes to resolve this Null
Pointer Exception, by creating constructors for the Round, StockRound,
OperatingRound and the sub-classes of StockRound. It does require
modifications of all of these for the constructors. A total of 8 classes to
update. (the sub-classes of OperatingRound does not require an update. But
probably should have constructors created for consistancy's sake.

The simple fix would have been to add
    this.companyManager = gameManager.getCompanyManager();

to the ShareSellingRound constructor. That works for me to fix the problem
(which I have reproduced). Not sure what you are trying to achieve by adding
all these constructors.

As for the second suggestion, I have indeed implemented the constructors
such that the super-classes do all the initialization that should, and the
sub-classes do the initialization they should. In a couple of places I
needed to create a constructor that simply called the super class
constructor and nothing more.  

I wonder why you are using worls like "required" and "needed": such default
constructors can be omitted.

I have noticed that XCode does warn about several classes marked as
deprecated (in your comments) that are still being used. But the deprecation
comment does not specify what should be used instead. Those might be a
better item to clean up then simply adding JAVA Docs.

Good point. Thanks.
 
Erik.

-------------------------------------------------------------------------
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
<http://moblin-contest.org/redirect.php?banner_id=100&url=/> &url=/
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Cleanups

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

Probably my warning settings are a bit lower than yours...

I still get about 30 warnings (I had 32 before)... --

getSpecialProperties () in rails.game.RoundI has been deprecated
percentageOwnedByPlayers() in rails.game.PublicCompanyI has been deprecated 

Removed (were unused). 

        getStatus() in rails.game.action.StartItemAction has been deprecated
 
Undeprecated (there must have been a good reason why I did it, but I don't
remember).

         getElement() in rails.util.Tag has been deprecated (in
ConvertTilesXML.java:167 and MakeGameTileSets.java:66,94,102)
 
Will stay so for a while. Your new map code may make these utilities
obsolete. I'll wait for that.
 
Erik.

 

Re: [Rails-devel] Cleanups

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

I still get about 30 warnings (I had 32 before)... --

getSpecialProperties () in rails.game.RoundI has been deprecated
percentageOwnedByPlayers() in rails.game.PublicCompanyI has been deprecated
getStatus() in rails.game.action.StartItemAction has been deprecated
getElement() in rails.util.Tag has been deprecated (in
ConvertTilesXML.java:167 and MakeGameTileSets.java:66,94,102)

Mostly the getSpecialProperties one.

Mark


On Tue, Dec 2, 2008 at 3:35 PM, Erik Vos <eri...@hc...> wrote:

>  I have noticed that XCode does warn about several classes marked as
> deprecated (in your comments) that are still being used. But the deprecation
> comment does not specify what should be used instead. Those might be a
> better item to clean up then simply adding JAVA Docs.
>
>
> I have cleaned up most of those, but also left in one that is only used in
> the external tile XML conversion utilities. Too lazy now to rework that
> code.
> And cleaned up more code based on the compiler warnings. The remaining
> warnings are inevitable, or refer to variables for future use or to the
> remaining deprecated method.
>
> Erik.
>
>
> -------------------------------------------------------------------------
> 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
>
>