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

Dynamic interruption behavior based on incoming command #6511

Open
LightspeedLazer opened this issue Apr 11, 2024 · 0 comments
Open

Dynamic interruption behavior based on incoming command #6511

LightspeedLazer opened this issue Apr 11, 2024 · 0 comments

Comments

@LightspeedLazer
Copy link

Is your feature request related to a problem? Please describe.
The current interruption behavior logic is a black and white "This command can be canceled" or "This command can't be canceled". This can be an issue especially if you have complex command logic and want to enforce certain rules on when certain commands can be scheduled.

Describe the solution you'd like
Command.getInterruptionBehavior gets a parameter that is the incoming command.

public InterruptionBehavior getInterruptionBehavior(Command incomingCommand) {
    return InterruptionBehavior.kCancelSelf;
}

This allows the currently running command to decide if it should cancel or not. This is nice for when you want to enforce a command hierarchy without having to have extra code at every schedule site.

Command.withInterruptionBehavior would take in a Function<Command,InterruptionBehavior> instead of just InterruptionBehavior.

Additional context
#6510 would help this a lot as it would be easier to identify which commands should cancel the current command.

public Command feed() {
    return startEnd(
        this::startFeed,
        this::stopIntake
    )
    .withTags(FEED_TAG)
    .withInterruptionBehavior((incoming) -> (incoming.hasTags(Intake.INTAKE_TAG) ? InterruptionBehavior.kCancelIncoming : InterruptionBehavior.kCancelSelf))
    .withName("Feed");
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant