Re: [Rails-devel] Price tokens change order when moving up.

[Stefan F. <ste...@we...>]

Erik,
seems to be a day of disagreements ;-)
But this makes discussion interesting and fruitful.
For the time being it is not mission-critical, where the sorting is done.
Mainly I was not happy about more things moved into those classes, which I 
would prefer to be smaller (more details below).
Stefan

On a general perspective:

From the perspective of a developer coming late to the project the GameManager 
and Round classes seems overloaded or even bloated already.
And it is much easier to guess that the operating order of public companies is 
defined by the PublicCompany class (and as it defines an ordering most likely 
as a comparator) instead of the GameManager. You (might) know everything by 
heart, but this makes it more difficult for the others.

I have to admit that most of my recent suggestions all intend to break those 
large classes into smaller pieces to allow easier and safer modifications.
Seems that we are moving in opposite directions here. 

Another admission: I already defined comparators for the Player and Company 
classes to have the GameReport sequence unique for the automated testing. 
There is even a class, which defines a sorting related to classes which all 
implement a common interface CashHolder (rails.util.SequenceUtil)
The latter would also be a place to put the sorting instead of the GameManager 
class.

On the specific task on hand:

My idea was to move only the ordering logic to the comparator (and if no price 
is yet defined put those at the end of sequence) and then have the specific 
methods only apply the filtering for floated companies.

By no means I did intend to suggest to move the filtering to the comparator, 
which is not possible as you rightly observe.

And on the company hierachy: 
I read the discussion (some years ago in the archive). I agree, I might have 
been even more drastic: Maybe one should even not have separate private and 
public companies classes (think about those operating privates in 1846). Even 
the fact that companies can operate or be purchased could be configured by 
attributes instead of defined by class (names).
I agree that in this case (as in many other cases like e.g. trains) the 
specific features should be configurable. If one wants to separate those 
features in different classes I would prefer composition instead of 
inheritance.

On Monday 05 July 2010 22:06:52 Erik Vos wrote:
> Stefan,
>
> I'm afraid this does not sound like a very good idea to me.
>
> AFAIK, a comparator requires *every* instance to be comparable. And
> non-started companies without a price aren't really well comparable for
> defining operating order purposes.
>
> Defining operating order (there are now two methods doing that, for
> different purposes and with different output) does not only require
> sorting, but also prior selection of the objects eligible for ordering.
>
> Yes, I realize that my new getCompaniesInRunningOrder() method does order
> *all* companies (contrary to everything I have said above), but (thinking
> about it) that's probably rather a bug than a feature. For now it works,
> but I don't consider it durable. In all likelihood the current logic will
> need major changes when adding games like 1837 and 1844 with their many
> different company types. And for such purposes I'd rather subclass
> GameManager (which must be done anyway in most new games) than
> PublicCompany.*
>
> Another consideration: recent developments increasingly force me to move
> logic out of the 'static' objects (companies, trains, tiles etc.) and into
> the 'dynamic' Manager/Round objects. Your proposal goes somewhat in the
> opposite direction.
>
> Erik.
>
> * That's a separate subject. Company class hierarchies have been discussed
> before in this forum. That might be a good idea if Java would support
> multiple inheritance, but it doesn't. There are too many company types with
> different mixtures of special features, and I have given up of thinking
> about catching these in hierarchies.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Sunday 04 July 2010 23:46
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Price tokens change order when moving up.
>
> Erik:
> do you mind if I move the definition of running order into the
> PublicCompany
>
> class and define a Comparator?
>
> I can still keep the new method in the GameManager, but the change would
> later
> simplify the migration to the new sequence model.
>
> Stefan
>
> On Sunday 04 July 2010 22:57:26 Erik Vos wrote:
> > (Switching to the proper group)
> > This has been fixed now - in Subversion!
> >
> > Erik.
> >
> >
> >   _____
> >
> > From: 18...@ya... [mailto:18...@ya...] On Behalf Of
> > John A. Tamplin
> > Sent: Friday 02 July 2010 00:17
> > To: 18...@ya...
> > Subject: Re: [18xx] par value marker movement
> >
> >
> >
> >
> > On Thu, Jul 1, 2010 at 3:43 PM, Erik Vos <eri...@xs...
> >
> > <mailto:erik.vos%40xs4all.nl> > wrote:
> > > At the end of the SR, the companies are scanned for being sold out in
>
> the
>
> > > order in which they appear in the Game Status window. Any upward token
> > > moves
> > > are then executed in that order and follow the normal move rules. So I
> > > suspect that the token order gets reversed only if a 'lower' company
> > > token is on top of a 'higher' one. Or it could be the reverse...:-)
> > > Indeed we need
> > > a saved file to prove that.
> > > In any case, I would encourage to file it as a bug, so it will get
>
> proper
>
> > > attention at some point.
> >
> > The tokens are supposed to be processed in market order, which winds up
> > preserving the same stacking.
>
> ---------------------------------------------------------------------------
>- --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel