DSL is mutating the states

[sabomichal]

This machine has one fundamental problem, that you can not instantiate more than one instance of the State Machine, since it is not building its own immutable State graph based on the State definition, but the DSL is mutating the inner state of the State itself.

[nsk90]

Hi! I wrote about it in "Do not" readme section. https://github.com/nsk90/kstatemachine#do-not

Mutable state graph will help if you use only default states (without data attached to them), but if you use DataState or your own State subclass the problem will be still actual.

I think it is easier to avoid using singleton states if you have more than one instance of same state machine, than add mutable state graph abstraction.

Does removing object from your state definitions help you or I missing something?

[sabomichal]

Ah, ok, I was unaware of that section.

Sure, you can always do it one way or the other and my issue description is a bit wrong - the mutable state definition is a limitation only when you define the states in advance, avoiding so the lateinit or stub states definitions at the beginning of the State machine definition.

[nsk90]

Yes, using object States may simplify state machine creation function.

The idea of mutable state graph is ok, so maybe it should be tried.

Attention also should be payed to:

• Do not dramatically break non-dsl usage.
• Make it clear that State with mutable data cannot be used across machine instances anyway.
• Another option is complete separation of a State and its data (but this seems to be more error prone)

[nsk90]

I took a look at the idea of moving State mutability to another object (state graph). Here are some points on that:

• Immutable and object states would make createStateMachine() function body simpler in some cases as there is no need to create variables for them. This also keeps the ability to create multiple machines holding same State objects.
• It is not possible to make all the states immutable (see DataStates, and State subclasses). So you have to think when it is valid to use object with a state or not. Multithreading environment will make it even harder.
• Making State immutable means that there is no reference to machine or state graph in it. This will cause ugly API where all State methods will accept additional argument (machine or graph object). Like firstState.isActive(graph) or from the graph point of view graph.isActive(firstState).
• Replacing existing parent, children and status references with a graph or machine reference in a State will not fix the original DSL mutating problem.
• From architecture point of view it might be little bit strange to share State instances across multiple machines.

So I do not think it should be implemented. If you have some thoughts on this, please share :)