Feature Request: filter_* => on_*

[Hirrolot]

Currently, we favour filter_* naming, such as Update::filter_message or filter_command or whatever. I suggest changing that to Update::on_message, on_command, etc.

(However, we should not change dptree::filter and its siblings, since dptree has less context than teloxide in general.)

Pros

• It's shorter.
• It's generally more adopted across many other libraries and frameworks.

Cons

• Deprecation needed.

Alternatives

• Don't do anything.

[WaffleLapkin]

I am not sure how I feel about this. On one hand, on_* does sound nice, but I'm afraid that it will lead to more confusion of that it actually does.

For example for filter_command we currently require that Message is in the context, so you need to filter_message().branch(filter_command().<...>). With on_* this looks more unintuitive, IMO.

[Hirrolot]

I don't know, as for me, filter_message().branch(filter_command()) is just the same as on_message().branch(on_command()). filter may be confusing too, since it doesn't explicitly state what dependencies are needed, does it?

[WaffleLapkin]

For me "on_x" feels more like handlers[x] = f i.e. execute function every time a particular event is being handled. But what our function actually does is change what update kinds are handled forward (and also change the context). So uhhh, I'm not sure it's a good fit.

filter may be confusing too, since it doesn't explicitly state what dependencies are needed, does it?

Yes, of course. Ideally ig we would check this at compile time, or at least have better docs that clearly highlight provide/require relationships between all the dispatch functions.

[Hirrolot]

Ok, let me think about that a bit. I'm currently working on some dptree PR that might make things simpler, and then will come back to the discussion.