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

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

>
> Issues that I see:
> 1. The StartRound_1830.java and StartRound_1835.java should be placed
> under the specific/_1830 and specific/_1835 sub-folders along with the
> other special case classes

Yes and no.
These classes pre-date the introduction of the game.specific package, and
are in fact not really game-specific. The 1830-style auction occurs in
many games, and I believe the 1835-style auction is also used in 1837.
At the time these classes were created I had a brief discussion with Brett
about the naming of such classes, but we couldn't find good generic names
for the different auction types. Perhaps StartRound1830Style would have
been better.

I have no real objection against moving these classes to game.specific,
but the above should be kept in mind.

> 2. The Round, StockRound, OperatingRound, and
> the respective subclasses do not have constructors for no elements, or for
> theStockRound (and sub-classes) an cosntructor with the GameManager  Round
> superclass should have (but doesn't).  The Round superclass does have a
> method 'setGameManager' which assigns gameManager and companyManager.
>
>
> 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.

I don't have the current code handy here at work (just an old version),
but I would think that a Round constructor should do all the common tasks,
and the next lower level (StockRound etc.) any additional tasks specific
to the type of round. So I'm not sure why all these classes need explicit
constructors. But I'll have a look tonight. I'm probably missing some
point.

I know that the whole initialization stuff is somewhat messy, so I am not
at all surprised that you are finding inconsistencies.

> Since I am creating new methods, should I also add in the JavaDocs for
> them as well?

Yes, of course that would be a good thing to do. I know I'm sloppy in
creating Javadocs, perhaps I can spend some time on that before the
upcoming release, if we're running out of bugs.

Erik.