| 9 | | This ticket is blocked by #2407. (Because I won't drastically modify the file structure before you commit my patch over there.) |
| | 9 | This ticket is blocked by #2407. (Because I won't drastically modify the file structure of input.js before you commit my patch over there.) |
| | 10 | |
| | 11 | == What is there == |
| | 12 | A rather basic implementation of one concrete state machine. (no abstraction) On closer inspection, it turns out those are actually a bunch of smaller state machines glued together along their entry and exit paths to a „default state.“ There is a second state machine as well, for postGui event processing. |
| | 13 | |
| | 14 | == Proposed change == |
| | 15 | A lightweight abstract system which does not know a lot about it's content. It has a state (Bandboxing, Building, Tribute), such a state describes the mechanics of a „smaller state machine“ from the current code. The outer wrapper is not a state machine (no transitions) as it does not posses any interesting feature. The inner state is not forced to be a state machine, it's internal structure is not inspected by the outer wrapper. As most of the „smaller state machines“ have just a single state, that prevents unnecessary abstraction. |
| | 16 | |
| | 17 | This untangles all the different features contained in that one function. |
| | 18 | |
| | 19 | Furthermore the central code of preEngine event handling and postEngine event handling can be unified. |
| | 20 | |
| | 21 | === Interface of a „state“ === |
| | 22 | Without specifying any particular structure yet, a state must allow the following: |
| | 23 | * Initializing it (The state receives a quitCallback to terminate itself) |
| | 24 | * Processing an event (returns whether it was eaten or not) |
| | 25 | * Terminating it |
| | 26 | |
| | 27 | == Open Questions == |
| | 28 | * May I split that file into many small parts? (selectionBox.js, orderStrutureBuild.js, ..) |
| | 29 | * What is your state on currying? |
