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

Command syntax, esp. optional arguments #51

Open
8573 opened this issue Jul 24, 2019 · 1 comment
Open

Command syntax, esp. optional arguments #51

8573 opened this issue Jul 24, 2019 · 1 comment
Labels
C-enhancement Category: Tickets requesting changes other than bug-fixes E-medium Difficulty: Medium P-high Importance: High
Milestone

Comments

@8573
Copy link
Owner

8573 commented Jul 24, 2019

In #50 (comment), @ctm wrote—

I've only been playing with irc-bot for about a day. I've found it easy to use, although I haven't yet figured out how to make a command that takes an optional argument. In specific, I'd like to be able to support bet, bet N (where N is a positive number), bet pot and bet half, but, at least when using the source from the dev branch of this repository, I get:

Error: While handling YAML: Expected <argument> to be of type Scalar, but it is of type Mapping.

for just bet, although bet "" works fine. I'm using "<amount>" as the argument to the syntax parameter of ModuleBuilder::command. I tried "...", but that fails to compile. With "<amount>", the zero-length string as input is converted to an empty Hash which is why yaml::check_type dies. I'm early enough into development that this doesn't really matter to me, and I realize there may be some other argument to syntax that might work.

Sorry about this! The API for defining commands, especially around taking arguments, is one of the older and messier ones, if not the messiest, and is so poorly documented that I can't even find any generated list of items for it in the documentation. (I suppose its "documentation" consists of the examples provided by the bot modules in src/modules.) Now that I have users other than myself, I realize that it well may be overly restrictive that the "commands" must take YAML objects as arguments, if they take any argument.

The way to have an optional argument like this with a command per se would be to make the argument a YAML mapping (what yaml-rust calls a Hash) and have the optional arguments be optional fields of that mapping, leading to an interface such as—

pokerbot: bet
pokerbot: bet amt: <N>
pokerbot: bet type: pot
pokerbot: bet type: half

However, it currently should be possible to get the interface you intended by using not commands per se but rather the similar feature currently named "triggers", which allow matching incoming messages against an arbitrary regex and running a given function for matching messages, with the regex's captures passed to the function. For your case, I imagine the regex would be ^bet(?: ([0-9]+|pot|half))?$.

These APIs deserve to be overhauled, and I imagine I might unify them into a single, more flexible API. Whether or not I do, I intend to rename triggers to something else, because, if eventually I write documentation for them, I otherwise would be talking about triggers being triggered and what triggers triggers, which could get confusing.

@8573 8573 mentioned this issue Jul 24, 2019
@ctm
Copy link

ctm commented Jul 25, 2019

Thank you very much for the quick response!

I did see that I could do a YAML mapping, but I didn't want my users to have to supply the key. We're old farts with muscle memory going back to the goodle days and we're happy to have any memory at all.

I did briefly see how triggers worked, but because of the name, I didn't think of them, especially since commands were so close to what I wanted to do that I fixated on them.

@8573 8573 added this to the v1.0.0 milestone Oct 5, 2019
@8573 8573 added C-enhancement Category: Tickets requesting changes other than bug-fixes E-medium Difficulty: Medium P-high Importance: High labels Oct 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: Tickets requesting changes other than bug-fixes E-medium Difficulty: Medium P-high Importance: High
Projects
None yet
Development

No branches or pull requests

2 participants