Description

Currently the RTM client api is a little bit clunky for more complicated clients because of the way that _callbacks is a class attribute not an instance attribute.

This sometimes forces the user to make annoying choices to avoid global variables when needing shared state between callbacks or when wanting to run two rtmclients in the same process with different implementations

For example, you're writing a bot that wants to look for it's own user_id in messages to figure out if it's directed at you. The easiest way to know your own user_id (without resorting to environment variables/constants) is to handle the "open" callback and store the user_id for later.

I looked into subclassing RTMClient but it gets a little clunky

To remedy this I'm proposing (and looking for feedback before I implement) a solution where the init argument to an RTMClient can be passed an optional parameter for a context object that is expected to contain the implementation for all callbacks.
If that argument is not null, then all the callbacks are expected to be instance methods of the instance that was passed in. All methods would follow the naming scheme of:
"event_handler_{event_name}"
these could be resolved either dynamically inside the dispatch methods or else resolved once during init to speed up runtime calls.

Can any of the key developers comment on whether this seems like a good idea/would it be accepted as a pull request/should it be implemented slightly differently?

What type of issue is this? (place an x in one of the [ ])

• bug
• enhancement (feature request)
• question
• documentation related
• testing related
• discussion

Requirements (place an x in each of the [ ])

• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've searched for any related issues and avoided creating a duplicate issue.