V2: Moving towards better API about telebot

[tucnak]

Blimey! You know what?

It is.

Just.

Perfect.

I'm in overdrive, baby!!!

I don't even care anymore because I'm in the process of making Telebot God Emperor Bot Thing so hey boys and girls chill out

[tucnak]

/cc @irgendwr

[irgendwr]

I really like the Idea of using reflection as a way of simplifying the send methods!
But wouldn't your proposed message builder mean that you have multiple ways of doing the same thing (ie. sending a message)? Might be confusing, idk.
The error handler would also be very useful to reduce repetitive error checking.

start/listen/serve is confusing

• I think Serve is kind of useless because when I define a handler I expect it to be called by default.
• Listen is weird as it's not really needed (see second example in readme; I also don't use listen) and is now also kind of getting replaced by Handlers.
  You could add Handlers for Message and Query events to fully replace Listen and the channel-thing.
• Couldn't Start also be merged with NewBot? Or is there a reason to have to explicitly define when the bot should start? Race-conditions should be unlikely presuming handlers are registered right after creation.

As you can guess I like the "There should be one-- and preferably only one --obvious way to do it." mentality 😄

[irgendwr]

I haven't used callbacks yet but they could probably be handlers too, registered per user/state or per message for example.

[tucnak]

I think Serve is kind of useless because when I define a handler I expect it to be called by default.

I couldn't introduce it any other way without breaking backwards compat. 😞

Listen is weird as it's not really needed

Fair enough! I kept it for backwards compat too, even though we can now let it go in v2.

Couldn't Start also be merged with NewBot?

Good question. I don't think so. All the receiving channels must be initialized when long polling starts, so we probably should stick to the 3-phase init process: NewBot, channels & handlers, and Start.

I haven't used callbacks yet but they could probably be handlers too, registered per user or per message for example.

I use callbacks for better UI mostly: inline keyboard buttons cause message updates. What's the benefit of "registering" callbacks as handlers and wiring them to messages, especially considering that associated messages are returned as a part of a callback struct?

[matteocontrini]

Any progress? It seems there hasn't been much activity after August 25...

[tucnak]

@matteocontrini No progress at all, I'm still pretty much waiting for feedback.

[tucnak]

FYI, I just added Send(), Reply() and Forward() the three "generic" methods. All of them accept 2+ arguments (recipient, payload and "options"). Since both payload and options are of type interface{}, it lets you pass either string or Sendable as payload and pretty much anything for options.

But what exactly is an "option"? Nice thing about this API is that by "options" it doesn't necessarily mean *SendOptions. Both *SendOptions, *ReplyMarkup and one of the const Options (which I'm still working on, but basically these are just fancy shortcuts) will work, following arguments overriding preceding ones. Look:

b.Send(user, "Message")
b.Send(user, photo, tb.ForceReply)

b.Send(user, photo, tb.NoPreview, tb.ForceReply)
// instead of
b.Send(user, photo, &tb.SendOptions{
    DisableWebPagePreview: true,
    ReplyMarkup: &ReplyMarkup{ForceReply: true},
})

// You can override some properties of stored options also:
savedOptions := &tb.SendOptions{}

b.Send(user, "text", savedOptions, tb.NoPreview) // overrides DisableWebPagePreview from `savedOptions` 

Let me know if there's anything that doesn't feel right.