The chatId parameter of GetChat method does not accept string

[amirhosss]

Hi, the official Telegram docs accept strings, but in this implementation, we can't pass a string.
https://core.telegram.org/bots/api#getchat

func (bot *Bot) GetChat(chatId int64, opts *GetChatOpts) (*Chat, error) {
	v := map[string]string{}
	v["chat_id"] = strconv.FormatInt(chatId, 10)

	var reqOpts *RequestOpts
	if opts != nil {
		reqOpts = opts.RequestOpts
	}

	r, err := bot.Request("getChat", v, nil, reqOpts)
	if err != nil {
		return nil, err
	}

	var c Chat
	return &c, json.Unmarshal(r, &c)
}

[PaulSonOfLars]

Hi, thanks for raising an issue!

This is a known limitation of the library, caused by go's static type system. It's not possible to have a method which accepts both a string and an int for the same parameter.

However, this limitation was found to be quite benign, as it is safer to write your bots using fixed chatids rather than usernames, which could change at any point.

If you really want to use a string, I recommend you use the bot.Request method to craft your own request. The example you've provided just needs a few tweaks to use strings instead of ints

[amirhosss]

Thanks

[zumoshi]

it is safer to write your bots using fixed chatids

I may agree with this on other methods (e.g. getChatMember), but my whole use case for getChat is to resolve the username provided by the user into the numeric chatId (which will then be stored in a db and used). since asking users to know/remember their channel id is not good UX.

@PaulSonOfLars Can this issue be reopened? I think Go's lack of method overloading can be worked around by adding duplicate methods.

i.e.

GetChat(int64,*GetChatOpts)
GetChatByString(string, *GetChatOpts)

While the workaround of using the underlying request method works, at that point we might as well directly make http requests and ditch the library. it loses all value of this library (e.g. getting notified of changes on api updates, preventing typos in parameter names, getting compiletime error in case of incompatible api change, auto complete, etc).

[PaulSonOfLars]

This has been discussed in great detail in #160, which is still open. Please continue the conversation there.