Dynamic handler management and registration context argument

[seckrv]

Please refer to the commit messages for a more detailed description.

[shawnanastasio]

Thanks for the PR. Looks like a useful addition. My main issue is that it seems to break backwards compatibility with older bots that expect only 2 parameters in their handler functions. A way to preserve backwards compatibility without over-complicating the library would be nice. Perhaps if the kwarg arg in add_handler is not provided, then the callback function would only be called with the original two arguments. On that note, I think None is a better choice for arg's default value since it would more clearly express that the feature isn't used by default.

Also, could you explain your reasoning for adding the triggers_on methods and the get_handler method which doesn't seem to be called anywhere? The functionality for an MHandler object to communicate whether or not it is to be handled (triggered) by a given event is already exposed via the test_command method. Perhaps I'm misunderstanding their purpose, though.

Finally (nitpick), I think the example generic_callback in example_bot.py could use a slightly more descriptive name. Perhaps something along the lines of custom_greeter_callback?

Thanks, Shawn

[MeRuslan]

Sounds good

[seckrv]

Sorry for the late reply. I was kind of busy the last weeks. I restored backwards compatibility, making the data argument optional.

Regarding your questions:

The get_handler function enables a bot implementation to retrieve a certain MHandler object, independent from the calling context. Imagine a command callback (e.g. "!deactivate cheers"), which dynamically wants to deactivate the MHandler, triggering on "cheers". In the calling context of the MHandler, triggering on "deactivate", without get_handler the program would have no access on the "cheers"-Handler.

The triggers_on function is needed for testing the trigger of a generic MHandler object, as MCommandHandler implements test_command and MRegexHandler implements test_regex. If you're iterating over an array of MHandler objects, you can't simply call test_command on all of them, as some may be of type MRegexHandler. Furthermore, for the invocation of test_command/test_regex the caller needs to provide room and event, which may not be available in every context, i want to test the trigger in. Finally, test_command will require the cmd_char to be in the given string, wich again may be unknown in the callers context.

Maybe my idea is now clearer. Thanks for your comments.

Cheers, Richi