proxy 
Here's the special sauce: a surgery step that can pretend to be a few different surgery steps. These proxy steps will, depending on the tool that's used, either continue to the next surgery step, or temporarily spin off a new surgery by adding new steps to the current surgery.
Vars | |
| branches | Optional surgery TYPES that we can branch out to Note that these must not share any starting tools. |
|---|---|
| branches_init | Initialized versions of types specified in branches. Don't fill this yourself, instead fill branches with surgery TYPES. |
| insert_self_after | Whether or not we should add ourselves as a step after we run a branch. This doesn't apply to failures, those will always add ourselves after. |
| overriding_tools | These tools are just...special cases. If we're using one of these tools and there's a tool conflict with the original surgery, just ignore any branches and continue with the original surgery. |
Procs | |
| try_next_step | Test the next step, but don't fully commit to it unless it completes successfully. If the next step doesn't fully complete (such as being interrupted or failing), we'll insert ourselves again to bring us back to the "base" state. If it does, we'll add the subsequent steps to the surgery and continue down the expected branch. If you complete the surgery step, it means you've committed to what comes next. Part of the motivation behind this is that I don't want to mutate a surgery retroactively. We can insert, but we shouldn't be changing anything behind us. |
Var Details
branches
Optional surgery TYPES that we can branch out to Note that these must not share any starting tools.
branches_init
Initialized versions of types specified in branches. Don't fill this yourself, instead fill branches with surgery TYPES.
insert_self_after
Whether or not we should add ourselves as a step after we run a branch. This doesn't apply to failures, those will always add ourselves after.
overriding_tools
These tools are just...special cases. If we're using one of these tools and there's a tool conflict with the original surgery, just ignore any branches and continue with the original surgery.
Proc Details
try_next_step
Test the next step, but don't fully commit to it unless it completes successfully. If the next step doesn't fully complete (such as being interrupted or failing), we'll insert ourselves again to bring us back to the "base" state. If it does, we'll add the subsequent steps to the surgery and continue down the expected branch. If you complete the surgery step, it means you've committed to what comes next. Part of the motivation behind this is that I don't want to mutate a surgery retroactively. We can insert, but we shouldn't be changing anything behind us.
Arguments:
- next_surgery_steps - the steps for the branching surgery to add to the current surgery. If there's no branching surgery (or this would continue the main surgery) ignore this.
- override_adding_self - If true, then on a successful surgery, regardless of the value of insert_self_after, we won't add ourselves in as another step.
- readd_step_on_fail - If true, when we fail a step we'll add the failed step again after the proxy surgery. This is necessary for main surgeries. (for other arguments, see try_op())