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

Rewrite as Filter system #4

Open
luckydonald opened this issue Jun 25, 2020 · 0 comments
Open

Rewrite as Filter system #4

luckydonald opened this issue Jun 25, 2020 · 0 comments

Comments

@luckydonald
Copy link
Owner

luckydonald commented Jun 25, 2020

Current situation

We have a separate list of update listeners, a list of command listeners and a list of messages to process.

This comes with a few disadvantages:

  • @on_updates are always executed first, then @on_message, and @command is always executed last. Which is not very flexible.
  • You can't easily add your own rules for listening to messages - you have to use a generic listener and implement the logic yourself, which isn't D.R.Y.

New Approach

We wanna have a Filter class,
having the following methods:

  • __init__(self, func: Callable, ...)
    This needs to take at least the func parameter, collecting the function to call on a match.
  • match(self, update: Update, ...)
    This will check that we can run this very function.
    Either raises an NoMatch(msg: str) exception, if we don't match, or returns a variable to use (or not use) in the call_handler later.
  • call_handler(self, update: Update, match_result)
    This will actually call the function registered with the correct parameters.
    This allows to supply any parameters for a function.
    For example the @command has a text parameter for everything after the /command.
    Note: Those has to be keyword parameters, so a function could stack different listeners, if needed. We also get provided the match_result, in case we did have some results there we don't wanna compute twice.
    Same @command already needs to take apart the string, so we get the text= parameter there. No need to redo that logic.
  • @staticmethod as_decorator(teleflask, *args, *kwargs):
    This shall be the easy way to use it as a decorator, the old Teleflask would simply call the fitting filter's as_decorator, when it's registering those.
    • do we need some kind of as_blueprint? Or can they simply wrap those in a lambda to call later?

Additional Benefits

  • This should make it easier to get away from those Mixin Classes
  • Also this should make the code of the Blueprint much easier, as we now have a simple list of filters we need to merge.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant