enhancement: DSL for final states; enhance to_dot also

[chuckremes]

When building state machines, I often have final/terminal states where any new event cannot cause a transition out of that state. I usually define it like so:

state :a_final_state do default :a_final_state, :log_event # transitions to self and logs the wayward event end

I'm "abusing" the #default event handler here a bit. It would be nice if this could be encapsulated as part of the DSL.

e.g.

final_state :a_state do event :any, :log_event # :any would be a magic symbol end

ALTERNATELY

trans :a_state, :any, :a_state, :log_event # again, :any is magic

Additionally, I would like to request that the #to_dot functionality be enhanced so that final states were indicated as such in the dot graphic. If I am remembering my DFA notation correctly, the final state(s) would have a double-circle around them.

[slagyr]

Why do you feel that using the #default handler is abusive?

Micah

On Jul 7, 2011, at 1:59 PM, chuckremes wrote:

When building state machines, I often have final/terminal states where any new event cannot cause a transition out of that state. I usually define it like so:

state :a_final_state do default :a_final_state, :log_event # transitions to self and logs the wayward event end

I'm "abusing" the #default event handler here a bit. It would be nice if this could be encapsulated as part of the DSL.

e.g.

final_state :a_state do event :any, :log_event # :any would be a magic symbol end

ALTERNATELY

trans :a_state, :any, :a_state, :log_event # again, :any is magic

Additionally, I would like to request that the #to_dot functionality be enhanced so that final states were indicated as such in the dot graphic. If I am remembering my DFA notation correctly, the final state(s) would have a double-circle around them.

Reply to this email directly or view it on GitHub: https://github.com/slagyr/statemachine/issues/6

[chuckremes]

I feel it's abusive because the intent in this situation isn't absolutely clear. Using new syntax (like #final_state) would make the intent very clear IMO.

Also, using the #default handler trick doesn't forbid adding more events to that state in the future. So, a state that was considered to be final could become non-final just by adding one more event.

e.g.

this one is final

state :foo do default :log_event end

this one is not final

state :bar do default :log_event event :oops, :error end

If we had syntax to enforce the finality of the state, the second situation would not be allowed.

e.g. final_state :baz do event :any, :log_event event :oops, :error # a second event definition is not allowed! end

Anyway, just a thought. I can clearly get what I need from existing syntax. My enhancement suggestion was merely to make the intent clearer.