Re: [Rails-devel] Train management

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

It seems to me from glancing at the rules that the 18EA trains are
equivalent to the various dual trains.  However, in 18EA, the train limit
changing never causes trains to be discarded to the pool - if a company
finds itself over limit due to phase change, it is allowed to stay over
limit.  Thus, the issue of train certificates in the pool is not relevant.

--
Chris

Please consider the environment before printing this e-mail.


On Mon, Jun 13, 2011 at 12:38 PM, Erik Vos <eri...@xs...> wrote:

> Thanks for the hint. Then MultiTrain or ChoiceTrain looks like a better
> name than DualTrain.
>
> Do such triple trains deviate in other aspects from the dual trains we
> know?
>
> The main point of considaration is the rule, that the choice cannot be
> changed when a chosen train is sold to another company, but erased when the
> train is discarded to the Pool?
>
> As discussed before, this rule is most explicitly stated in 18VA, but so
> far assumed to hold for all such choice trains.
>
>
> Erik.
>
>
>
> *Van:* Chris Shaffer [mailto:chr...@gm...]
> *Verzonden:* maandag 13 juni 2011 20:58
>
> *Aan:* Development list for Rails: an 18xx game
> *Onderwerp:* Re: [Rails-devel] Train management
>
>
>
> Note that, in 18EA there are triple train types - trains can be either
> freight or express or local.
>
>
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
> On Mon, Jun 13, 2011 at 8:59 AM, Erik Vos <eri...@xs...> wrote:
>
> > -----Oorspronkelijk bericht-----
> > Van: Stefan Frey [mailto:ste...@we...]
>
> > If you have flipTrain subclassing Train or have both be implementations
> of
> > the interface trainI is up to you. However I prefer the latter and trainI
> is an
> > unnecessary, as imho there is no need for an interface with only one
> > implementation (unless you provide an official API).
>
> We have many redundant interfaces, and I'd rather get rid of all of them,
> but there seems to be (or have been) a school of thought with some
> influence
> in this project that maintains that such interfaces are required about
> everywhere, just in case.  I prefer to use interfaces only when there is a
> actual need to provide some common functionality to classes in completely
> different hierarchies (good examples we have are the CashHolder, Moveable
> and MoveableHolder interfaces).
>
> We'll find out whether or not we really need TrainI when developing the
> dual
> train class; I will consider both options. This could the only other train
> class we will ever need: even the 18EU Pullmann has (right or wrong) been
> implemented with the standard Train class; its peculiarities are handled by
> special code.
>
>
> Erik.
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>