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

chat_id need to accept type of int and string #53

Open
DinoLeung opened this issue Apr 27, 2019 · 5 comments
Open

chat_id need to accept type of int and string #53

DinoLeung opened this issue Apr 27, 2019 · 5 comments
Assignees
Labels
bug Something isn't working duplicate This issue or pull request already exists

Comments

@DinoLeung
Copy link
Owner

DinoLeung commented Apr 27, 2019

Describe the bug

Currently it only accept id(int), however according to the official docs, it needs to accept username(string) also

Unique identifier for the target chat or username of the target channel (in the format `@channelusername`)

https://github.com/dart-lang/sdk/issues/4938

@DinoLeung DinoLeung added the bug Something isn't working label Apr 27, 2019
@DinoLeung DinoLeung self-assigned this Apr 27, 2019
@DinoLeung DinoLeung changed the title chat_id need to accept type int and string chat_id need to accept type of int and string Jul 13, 2019
@castaway
Copy link

Any likelyhood of applying the patch?

@DinoLeung
Copy link
Owner Author

DinoLeung commented Jul 29, 2020

@castaway I'm opposed to use dynamic in the library, as it beat the purpose of having it statically typed. I have been looking into sealed_unions which does union type, still not decided to use it or not.

@castaway
Copy link

Fair enough, could always make a sendChatMessage, sendUserMessage ? Or always take a string, and convert to int when sending if it parses as one?

@DinoLeung
Copy link
Owner Author

@castaway changing function parameters type would be considered a breaking change, which means it would break all existing bots depends on this library.

Although adding seperated implementation for each send message function would fix the issue we face, it also add unnecessary complexity to the project.

It is indeed a tough decision to make.

@DinoLeung DinoLeung added WIP duplicate This issue or pull request already exists and removed WIP labels Aug 20, 2020
@DinoLeung
Copy link
Owner Author

#99 has a better idea

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working duplicate This issue or pull request already exists
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants