-
Notifications
You must be signed in to change notification settings - Fork 597
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
Builder paradigm overhaul, second attempt #2024
Conversation
7ff0b7e
to
3937599
Compare
4933648
to
eff57b6
Compare
017b5c8
to
60b8799
Compare
Well then, I think this PR is now ready for review. I've gone through and reworked everything in the As I've gone through, any extra breaking changes in each builder, such as removal of methods, or changing field types, have been noted in the corresponding commit messages. I could compile them all together if desired. I think this should land after v0.11.3 is released, because there are some changes in |
f06e6e7
to
b6d6ce0
Compare
This includes reworking `CreateGuildWelcomeChannel` as well, which means removing `EditGuildWelcomeScreen::create_welcome_channel` as it is now made redundant by the `add_welcome_channel` method.
Changed `CreateComponents::set_action_rows` to overwrite the list of action rows, rather than extend it. Added `add_action_rows` to do that instead. Removed the following builder methods, as they became redundant: - CreateComponents::create_action_row - CreateActionRow::create_button - CreateActionRow::create_select_menu - CreateActionRow::create_input_text - CreateSelectMenuOptions::create_option Also, replaced all `set_components` methods with just `components`.
Removed the following now-redundant methods: - CreateApplicationCommands::create_application_command - CreateApplicationCommand::create_option - CreateApplicationCommandOption::create_sub_option - CreateApplicationCommandsPermissions::create_application_command - CreateApplicationCommandPermissions::create_permissions - CreateApplicationCommandPermissionsData::create_permission Also, made a note that `CreateApplicationCommandsPermissions` and the methods that call it no longer work, due to the endpoint being disabled.
Also changed model methods on `Guild` and `PartialGuild` to take `&self` instead of `self`.
d0cc1ea
to
99c0788
Compare
Rebased on next now that #2061 was merged, and also reworked the new EditAutoModRule builder and the new Webhook example. Should be all set for review. EDIT: For some reason, github's listing of the commits above has some out of order/duplicated. I'd recommend just using the commits tab to get a list of all commits. |
After working for a while on #1967, I realized that there were problems with the approach I was taking, and that solving them would require rewriting a good portion of what had already been pushed. So, I'm going to take a fresh start and hopefully get it right this time. Again, the goal is reduce monomorphization bloat due to generic closure arguments, allow for re-using preconstructed builders, and pave the way for later changes down the line that bring the library more in line with Discord's official docs (e.g. enforcing required fields, implementing
audit_log_reason
, etc.).Here is the new plan:
async
and their return types will be unchanged, but they will now take a concreteBuilder
type as argument instead of a generic closure likeFnOnce(&mut Builder) -> &mut Builder
.execute
method that performs the API request. This helps in cases where model methods duplicate functionality betweenGuild
/PartialGuild
/GuildId
, orGuildChannel
/ChannelId
, etc. I am initially in favor of exposing this method to users, though we may want to mark itpub(crate)
instead, depending on consensus.Builder::default().method1().method2()
, methods on builders will take and returnSelf
instead of&mut Self
.