Re: [Rails-devel] Rails2.0: ChangeStack and ChangeSet

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

Erik:
thanks for your comments: Some quick replies, see below.
Stefan

 >
>> Remark: This is different to Rails1.x, for which some State changes could
> get
>> lost, as there was no open ChangeSet available at the time of processing.
>
> The explicit opening and closing of MoveSets was intentional, to make sure
> that no changes would exist outside of the "change window" after receiving
> and validating a player action.
> Just a matter of trying to ensure some programming discipline: any change
> outside that window was considered illegal.
> Unfortunately, I never got to catch such illegal changes, so the only way to
> find these errors was inspecting the logs.
> (This omission has been the cause of several undo bugs, so this incomplete
> cure may have been worse than the disease.)
>
> In fact you are dropping this change window concept, allowing changes at any
> time.  Two further comments on that:
>
> 1. You no longer can enforce that no changes are done before validation is
> complete.  Any such premature changes will now end up in an open
> AutoChangeSet.
> I would prefer an approach where whatever changeset is open would be closed
> before the engine passes control back to the UI, and any premature changes
> when no changeset is open should be catched somehow, perhaps by throwing an
> exception. I'm not sure if that is practical, however; if not, I may have to
> settle with your approach, although somewhat reluctantly.
>

It is possible to add that behavior, by adding an explicit lock to the 
ChangeStack. Maybe we could even make the behavior then different in 
development (fail) and production (only error in log). For me that is 
not a property of the ChangeSet, but more of the ChangeStack itself.
Then you could lock e.g. during validations.

I did not spec it until now, as it was not correctly implemented in 
Rails1.x and was more a source of errors than a feature.

For me this is different to open and close of ChangeSets (open means 
that ChangeSet accepts additional changes, closed means that it will 
NEVER accept any additional changes).

> 2. I'm not sure if 'action' and 'auto' changes can be separated so easily,
> in the sense that the latter always follow the former. Did you check that?
> I'm particularly thinking of special cases like the CGR formation, where
> player and auto actions seem rather intertwined to me.

It is not easy in ALL cases, but it is easy in MOST cases. And as it 
only informational value, it is not an issue if it is done wrong.

It will be
* Start ActionChangeSet (closes AutoChangeSet)
* Process Action
* Close ActionChangeSet (opens AutoChangeSet)
* Game Processing
* Start ActionChangeSet (closes AutoChangeSet)
* Process Action
and so on...

Game Processing could be split in separate parts
* Last Action in SR processed
* AutoChangeSet open
* End of StockRound in-game processing (e.g. share price changes due to 
shares sold out)
* Open next AutoChangeSet
* In-Game OR processing (e.g. income of privates)
* Start ActionChangeSet
* Process Tile Lay Action
and so on...

The "base" functionality of ActionChangeSet and AutoChangeSet is 
identical, it merely defines the "owner" of changes and this could be 
used in displaying user comments and the game reports.

What I have not mentioned so far is I intend to make user Comments and 
Report Text (sub-)components of the ChangeSets in future Rails2.0 
development.

>
> 3. Do you still link change sets so that these can only be undone as a
> whole?
>

There is an implicit link of ActionChangeSets to AutoChangeSets as 
undo/redo will always jump to the next action. So all AutoChangeSets 
will be undone automatically.
I consider linking ActionChangeSets that belong to separate actions as 
harmful, as in my opinion it always indicate an inherent undo problem, 
which should be fixed instead of artificially linking the actions.