Giving guards access to state

[thejpster]

Would it be possible to pass the guard functions an &self reference to some context type T, so they can check some other local state before returning true/false? I used context types in menu-rs, but I'm not sure that's a brilliant example.

[korken89]

For now this is not possible (but on the top of the TODO list), but if you check the TODO in the readme - what do you think about the proposed syntax for adding context and data to events?

[bgourlie]

I prefer the 1st proposed syntax:

statemachine! {
    type: MyStateMachine,
    context: MyContextStruct,
    transitions: {
        *State1 + Event1 = State2,
        State2 + Event2 = State3,
    },
    values: {
        Event1: Type1,
        Event2: Type2
    }
}

Perhaps renaming "values" to "mappings.".

[korken89]

Thank you for the feedback!

I will soon start expanding the macro to support the type and values/mappings part.

context needs some more thought on how to access it, and if the context should be able to have access split up into different states.

[bgourlie]

I was thinking about the context idea and had an idea that seems like it would be pretty flexible.

Instead of specifying a context struct, you could specify the name of a trait (to be generated) that all the guard/action methods would be defined on, which would all take a reference to &self. The state machine would be generic over the context trait. You would specify the concrete context type during the call to StateMachine::new().

[korken89]

Context now available, will look into passing the event to the guard and action as well

[korken89]

All is now supported