-
Notifications
You must be signed in to change notification settings - Fork 2
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
abort() - Abort Signal #36
Comments
This would effect a new minor release ie 2.1.0 |
{
brand: 'Signal'
type: 'abort'
value: a PipeValue
} similar to Pipe object |
Ideas
1 & 2 would be supported in Chain and the optional |
{
brand: 'Abort_Signal'
assembledLines: 1 // default is 1, the assembled line that the BotAction is in who returned this object
pipeValue?: a PipeValue
} edit: implemented as Special case added, assembledLines = 0, which aborts the entire bot with whatever optional |
Trying to think of other "signals" besides "aborting" that could be useful for an assembled BotAction to "communicate" with the BotAction that assembled it... Edit: Edit2: Edit3: |
In the spirit of maximizing code value, I'm leaning towards the more static #36 (comment) over the more dynamic #36 (comment) There's more time needed to write the dynamic solution, its unit-tests, maybe more bug fixes since it's slightly more complicated, etc when it might not be used at all. Also, making it dynamic opens the door to patterns that reduce the declarative nature of the system. One of the aspects of the declarative nature in Botmation is the order of the BotActions assembled is maintained as a truth one can rely on ie while quickly skimming code. If I were to add dynamic assembly via "signals", then the order can be "spliced" with "random" BotAction's from a deeper context. That harms the reliability of the order of BotAction's always being true, therefore harming one's ability to quickly skim code, read code therefore maintain code, etc. Readability is important. If you can make your code predictable, even better. |
Ideas
Therefore, For simplicity, |
Therefore, the |
Tip Similar to Edit: |
Abort Signal support built into assembling BotAction's in PR #66
|
This BotAction would return a Promise that resolves a signal like:
When a BotAction returns an object like this, the actions runner will check the returned value for matching this signal and if it is, it doesn't process any more actions.
The action runners would then check every action's return value except the last action, since that can just return up the context to the higher runner to kill that instead.
This would effectively change chain()() and the default BotAction to return
Promise<void>
orPromise<KillSignal>
, unless killing an actions runner is a pipe only feature....It would be handy with the
switchPipe()
concept as a means to kill the actions runner, but in this case, if a case() returned a signal that it ran (therefore had at least one matching value, to cause it to run its actions) -- abreak;
equivalent.The text was updated successfully, but these errors were encountered: