Hello everyone!
Problem:
Methods in Api.h currently have very long parameter lists. For example, sendMessage takes 11 parameters. This leads to cumbersome function calls with many default arguments (e.g., nullptr, 0, or false) just to access a specific parameter at the end of the signature.
For example, if I only need to set the businessConnectionId, I'm forced to write the following:
bot.getApi().sendMessage(
id,
textMessage,
nullptr,
nullptr,
nullptr,
"",
false,
std::vector<TgBot::MessageEntity::Ptr>(),
0,
false,
businessConnectionId
);
Writing 8 lines of default values takes up space and makes the code difficult to read, as it's impossible to understand what each nullptr or false value means at a glance.
Proposed solution:
Introduce parameter structures (Options structures) for methods with multiple optional parameters (e.g., SendMessageOptions, PromoteChatMemberOptions, etc.).
The call would then look like this:
SendMessageOptions sendMessageOptions{};
sendMessageOptions.businessConnectionId = businessConnectionId;
bot.getApi().sendMessage(id, textMessage, sendMessageOptions); This will significantly improve readability. We know exactly which optional parameters are changing, and we write less code.
Questions for the community and @reo7sp:
Since updating the Api class is a major architectural change, I'd like to consult with you before starting:
-
Is this change desirable?
-
Should existing methods be refactored or overloaded (to ensure backward compatibility with previous versions)?
-
Should structs contain only optional parameters (keeping mandatory ones, such as chatId and text, in the function signature) or all parameters?
I'd appreciate your thoughts and feedback on this!
Hello everyone!
Problem:
Methods in
Api.hcurrently have very long parameter lists. For example,sendMessagetakes 11 parameters. This leads to cumbersome function calls with many default arguments (e.g.,nullptr,0, orfalse) just to access a specific parameter at the end of the signature.For example, if I only need to set the businessConnectionId, I'm forced to write the following:
Writing 8 lines of default values takes up space and makes the code difficult to read, as it's impossible to understand what each
nullptrorfalsevalue means at a glance.Proposed solution:
Introduce parameter structures (Options structures) for methods with multiple optional parameters (e.g.,
SendMessageOptions,PromoteChatMemberOptions, etc.).The call would then look like this:
SendMessageOptions sendMessageOptions{}; sendMessageOptions.businessConnectionId = businessConnectionId; bot.getApi().sendMessage(id, textMessage, sendMessageOptions);This will significantly improve readability. We know exactly which optional parameters are changing, and we write less code.
Questions for the community and @reo7sp:
Since updating the Api class is a major architectural change, I'd like to consult with you before starting:
Is this change desirable?
Should existing methods be refactored or overloaded (to ensure backward compatibility with previous versions)?
Should structs contain only optional parameters (keeping mandatory ones, such as
chatIdandtext, in the function signature) or all parameters?I'd appreciate your thoughts and feedback on this!