Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: event data matching #24

Open
x37v opened this issue Oct 15, 2021 · 2 comments
Open

Feature: event data matching #24

x37v opened this issue Oct 15, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@x37v
Copy link
Contributor

x37v commented Oct 15, 2021

Following on to my question in #23, I'm realizing that guards won't solve my problems, specifically, I'm implementing a series of menus that are driven by a pad of 16 buttons.. I'm trying to avoid creating unique events per button press/release while also allowing for using constants to identify details of the event matching so that I might easily use that same data to identify where to display something and potentially change the value of the constant (button that represents the transition/display area) in the future.

I'm wondering if it would make sense to expand the Event syntax to allow for pattern matching, so you can reuse the same event but with different patterns to specify different transitions:

const FOO_INDEX: usize = 2;
const BAR_INDEX: usize = 3;

pub struct ButtonData {
  pub index: usize,
  pub down: bool
}

statemachine! {
    transitions: {
        *State1 + Button(ButtonData { index: FOO_INDEX, down : true }) = State2,
        State1 + Button(ButtonData { index: BAR_INDEX, .. }) = State3,
    }
}

which I assume would generate code somewhat like:

pub fn process_event(&mut self, mut event: Events) -> Result<&States, Error> {
    match self.state {
        States::State1 => match event {
            Events::Button(ButtonData { index: FOO_INDEX, down: true })  => {
                self.state = States::State2;
                Ok(&self.state)
            }
            Events::Button(ButtonData { index: BAR_INDEX, .. })  => {
                self.state = States::State3;
                Ok(&self.state)
            }
            _ => Err(Error::InvalidEvent),
        },
        States::State2 => match event {
            _ => Err(Error::InvalidEvent),
        },
        States::State3 => match event {
            _ => Err(Error::InvalidEvent),
        },
        _ => Err(Error::InvalidEvent),
    }
}
@x37v
Copy link
Contributor Author

x37v commented Oct 15, 2021

I could also see allowing for the match guard style syntax:
*State1 + Button(ButtonData { index, down : true } if index < 20) = State2

@x37v
Copy link
Contributor Author

x37v commented Oct 25, 2021

BTW.. i ended up forking and implementing an approach that allows for patterns in events and uses match guards to implement the guards.. its a bit more verbose and less "tied together" (you have to implement the Events enum yourself).. but has some other benefits..

https://github.com/x37v/smlang-rs

I figure its a relatively big departure so I'm not sure if a PR to get it back here would make sense.

here is an example of the DSL:

statemachine! {
   transitions: {
        *State1 + ButtonEvent(Button { down: true, .. }) / ctx.action(event); = State2,
        State1 + ButtonEvent(_) [!event.down] / {ctx.action(event)} = State3(2),
        State1 + FooEvent("blah") = State3(30),
        State3(usize) + ButtonEvent(Button { down: true, ..}) [event.index == 20 && *state < 20]
            / { ctx.action(event); println!("foo {}", state) } = State3(ctx.action2(*state, event)),
        State3(usize) + ButtonEvent(Button { down: false, ..}) = State3(*state + 1),

        //can't express State3(0) + FooEvent = State1 but can use a guard
        State3(usize) + FooEvent("blah") [state == &0] = State1,
        State5(StateData) + FooEvent("blah") [state.num == 0] = State1,
        State5(StateData) + BarEvent(0) = State1,
   }
}

@dzimmanck dzimmanck added the enhancement New feature or request label Jan 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants