alexpeachey / end_state

A State Machine implementation
MIT License
9 stars 5 forks source link

Transition Syntax #16

Closed charlierudolph closed 10 years ago

charlierudolph commented 10 years ago

Started working on building an example that is equivalent to the state_machine vehicle in its readme and ran into something.

The transition methods doesn't really seem powerful enough. Cannot give two transitions the same event name or define multiple with the same name at once.

# Second one overwrites the first (in terms of the definition of shift_up)
transition idling: :first_gear, as: :shift_up
transition first_gear: :second_gear, as: :shift_up

# Does not define the second transition
transition idling: :first_gear, first_gear: :second_gear, as: :shift_up

Use of any_state is not powerful enough. Something possible in state_machine

transition all - [:parked, :stalled] => :stalled

I think end_state needs to support both a combined syntax (listing multiple transitions at once to use same event name and other configuration and individual syntax (where event names are additive instead of overwriting) so each can have their own configuration.

Might be nice to add the ability to define guards / actions / concluders similar to state_machine where you list the specific transitions you want it to apply to and then just give the class and it adds it to that specific transition.

I think end_state should match the power of state_machine at least in the supported syntax. Then the only different is just the modularity which is what really separates them.

Thoughts?

alexpeachey commented 10 years ago

I think it would be reasonable and not difficult to add support for both of these:

transition idling: :first_gear, first_gear: :second_gear, as: :shift_up
transition idling: :first_gear, as: :shift_up
transition first_gear: :second_gear, as: :shift_up

I can't see any reason not to make that enhancement. It should be straightforward.

alexpeachey commented 10 years ago

Addressed in v0.12.0.