You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea is that instead of storing commands the same way we store rules we could use a map of (name, rule). For instance, a command is a specific case that we can optimize for, and we probably want to handle them slightly differently than generic rules because we could add more feature (like bot owner defined command aliases, sub-commands, and so on).
This idea works based on the components of a command: a prefix and a name, with some optional captured arguments. We can take advantage of this generic form to create a single regex that will match "this is a command", get its name, and inspect a mapping index of name to rule handlers.
We would still need to check if the rule handler matches the trigger, because:
sub-commands exist and the command name might not be enough to actually match (for a command that requires a sub-command)
for compatibility reason, we need to make sure that the trigger given to the plugin callable is the exact same as of today, and matching it again will give us that
Problems Solved
The first problem is a performance issue: as of today, if you have 100 commands registered, each trigger will try the match each of them. With the new suggested approach, Sopel will try at most twice: once to check if there is a command with that name, and a second time for the specific command match itself.
The second problem is more about the possibility of adding other features. Not that it's impossible to do command aliases per se, but it would be more complex to do without a rather simple index of name to rule handler.
Notes
It would probably help with #1818 to implement such index, because it would provide a fast and straightforward way to get any command from its name only, and map that to aliases (which are just pointer at this point).
The exact details of the data structured needed are not clear yet, but I'm sure we can figure that out while working on the implementation.
The text was updated successfully, but these errors were encountered:
Requested Feature
The idea is that instead of storing commands the same way we store rules we could use a map of (name, rule). For instance, a command is a specific case that we can optimize for, and we probably want to handle them slightly differently than generic rules because we could add more feature (like bot owner defined command aliases, sub-commands, and so on).
This idea works based on the components of a command: a prefix and a name, with some optional captured arguments. We can take advantage of this generic form to create a single regex that will match "this is a command", get its name, and inspect a mapping index of name to rule handlers.
We would still need to check if the rule handler matches the trigger, because:
Problems Solved
The first problem is a performance issue: as of today, if you have 100 commands registered, each trigger will try the match each of them. With the new suggested approach, Sopel will try at most twice: once to check if there is a command with that name, and a second time for the specific command match itself.
The second problem is more about the possibility of adding other features. Not that it's impossible to do command aliases per se, but it would be more complex to do without a rather simple index of name to rule handler.
Notes
It would probably help with #1818 to implement such index, because it would provide a fast and straightforward way to get any command from its name only, and map that to aliases (which are just pointer at this point).
The exact details of the data structured needed are not clear yet, but I'm sure we can figure that out while working on the implementation.
The text was updated successfully, but these errors were encountered: