Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

See comments below

On Tuesday, January 03, 2012 08:27:16 am Frederick Weld wrote:
> Regarding "a train":
> One option to accomodate both Erik's and Stefan's approach would be as
> follows: Each 18xx variant has a set of trains that are relevant for
> checking routes. For performance reasons, this set should be minimal.
> So for 1830 it would be {2} and for 18VA (if it had route-dependent
> enforcement) would be {2,1G}. The adapter's route check would be run
> with this set.

That is possible, however I do not recommend to implement features potentially
never used. From my experience after some time they get untested and/or 
unmaintained. For the time being I would define a static global inside 
RevenueAdapter.

And I doubt that you have to worry about the performance, if you run each 
train separately (this was the minor "bug" in your implementation: It you want 
to test many trains, it is much faster to run each once). And you could even 
stop after the first intermediate update that a solution is found, as you do 
not care for the optimal solution.

> 
> Regarding "each consumer directly accesses the algorithm package":
> Functionally, Stefan has made a valid point. But having performance in
> mind, it might be better if network information would not always be
> built from the scratch for each kind of check in every consumer. For
> example, in SimTex's 1830, network information (both used for UI/AI)
> is built/updated after each action. The needed component
> ("NetworkState") would reside below the game engine consumers and
> either be part of the game engine or be placed on top of it. But
> perhaps such design is only the target in the longer term.

I thought about that (Alex suggested it as well some time ago): However I see 
many more advantages keeping algorithm stateless. All state information is 
stored inside the Rails game engine. Consider the algorithm defining an 
appropriate view on the Rails database first and throwing away the data after 
each use.

And think about the consequences: 
* Everything you want to store have to be Rails state variables (to allow 
undo). 
* You have to define triggers from all actions that might change the network.
* There are lot of optimization that still have to be run each time again.
* Most likely you will have to keep a network per company.
* Debugging will be horrible in those cases where the Rails engine state and 
the Network state gets out of synch.
* And the performance gain is minimal, as the time needed for route 
calculation by far exceeds the required time of creating the network.

> 
> Regarding "suggest vs. enforce":
> Thanks to Stefan for pointing out this pitfall. Actually I had
> envisaged "enforce" (not "suggest") during development. Would it be
> acceptable to introduce the new mode "suggest & enforce" if only some
> aspects are enforced (train purchase) and others not? I ask that
> because the gain of applying the forced train purchase logic for
> displaying a different info message would be not too big (in my
> opinion).

From my point of view I would not add this to Rails 1.x, but in the end this 
is up to you.