-
-
Notifications
You must be signed in to change notification settings - Fork 316
Add new extension: DSharpPlus.Commands #1680
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
Conversation
|
as a first thing before i start reviewing: we should probably consider naming it something like Commands without suffix; and i believe the same pull request should also annotate |
|
Because the rest of DSharpPlus is on .NET 7, I've chosen to keep CNext and Slashies not obsolete until .NET 8 releases |
|
that'll be in a few days, and probably before merging this PR |
|
Done |
|
Before any documentation work happens, i would suggest to archive old command articles, instead of removing them completely |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overarching points:
consider renaming DSharpPlus.Commands.Commands. since it mostly deals with construction of a command tree; DSharpPlus.Commands.Trees?Done - Lunar- i really don't like multiple types in one file, it makes it harder to find these types later
- what exactly is the DX for configuring different processors? this seems a little doubtful given the implementation, but maybe you have a solution
- attributes should never contain logic, and much less throw exceptions. i believe @Instellate had a good design for checks in #1553
- this looks like it is restricting text commands to the same or similar parameters as application commands, which i don't exactly like - application commands are relatively limited, ie in nesting depth and in not supporting overloads.
DSharpPlus.Commands/Processors/TextCommands/Parsing/DefaultTextArgumentSplicer.cs
Show resolved
Hide resolved
DSharpPlus.Commands/Processors/TextCommands/Parsing/DefaultTextArgumentSplicer.cs
Show resolved
Hide resolved
DSharpPlus.Commands/Processors/SlashCommands/SlashCommandProcessor.cs
Outdated
Show resolved
Hide resolved
DSharpPlus.Commands/Processors/BaseCommandProcessor/ICommandProcessor.cs
Outdated
Show resolved
Hide resolved
|
|
||
| public interface IArgumentConverter<TEventArgs, TOutput> : IArgumentConverter where TEventArgs : AsyncEventArgs | ||
| { | ||
| public Task<Optional<TOutput>> ConvertAsync(ConverterContext context, TEventArgs eventArgs); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my experience I use argument converters for some network related calls, such as to a db or external website. Shouldn't task be used when the CPU is idling?
What do you mean by DX? |
|
developer experience, as in, how tedious is it to configure a command processor |
| } | ||
| } | ||
|
|
||
| // If we didn't find the user in the guild, try to get the user from the API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont like making hidden calls in converters maybe we can introduce a option to configure if we should make calls here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah we can do that
| { | ||
| add | ||
| { | ||
| if (this.UseDefaultCommandErrorHandler) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should toggle this.UseDefaultCommandErrorHandler when we unregister it
| this._commandErrored.Register(DefaultCommandErrorHandlerAsync); | ||
| } | ||
|
|
||
| // Attempt to get the user defined logging, otherwise setup a null logger since the D#+ Default Logger is internal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should open internals when merging
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should generally revamp that logger
| } | ||
|
|
||
| [SuppressMessage("Roslyn", "CA1859", Justification = "Incorrect warning in NET 8-rc2. TODO: Open an issue in dotnet/runtime.")] | ||
| private async Task<DiscordApplicationCommandOption> ToApplicationParameterAsync(Command command, CommandParameter parameter, int? i = null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a bit more describtive parameter name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's... the parameter you're converting to an application parameter. How much more descriptive could it get?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was talking about the last parameter, its confusing when you read a long method and then theres a random i
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OH. Yeah I can do that
DSharpPlus.Commands/Processors/TextCommands/Parsing/DefaultTextArgumentSplicer.cs
Show resolved
Hide resolved
…ong as all extra parameters have default values
…checks for message content; warn when missing required intents
|
All changes and review comments will be moved into issues as we need to start receiving user feedback soon. Merging into nightlies. |
|
i'll take a cursory look for intolerable flaws and then sign off on this |
|
|
inftord
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i will probably make a separate issue/pr about xmldocs, and gonna write some of those myself.
other than that, lgtm!
* Oops! I sneezed. * One of you hooligans needs to fix your IDE formatting. `dotnet format` * Fix context menu processors requiring exact types instead of ish types * ConfigureCommands event from #1680 * Documentation; Changed equality implementation on `ConverterDelegateFactory`; Fixed runtime startup exceptions * Move `GetConverterFriendlyBaseType` to `IArgumentConverter` to prevent static implementation on every command processor * Several bug fixes to argument parsing and conversion logic - Finish moving `GetConverterFriendlyBaseType` - Prevent `AddConverter` from throwing when the same converter is attempting to be added again - Early return on `ParseParametersAsync` when no parameters need to be parsed - Move default value logic from `ParseParametersAsync` to `ParseParameterAsync` - `ParseParameterAsync` now provides the value that failed to parse when returning `ArgumentFailedConversionValue` - `ExecuteConverterAsync<T>` now handles multi-argument parameters * Shadow `InteractionConverterContext.Argument` so `ConverterContext.Argument` can still be the raw value * Fix enum parsing for text commands, which now properly supports boxing (is it called boxing?) * There can only be one reply to a Discord message * Defer multi-argument parameter parsing to the base implementation * Theoretically add support for `TextMessageReplyAttribute` to most argument converters * Use `IArgumentConverter.GetConverterFriendlyBaseType` * Configure commands event args. This is non-negotiable. * Use `IArgumentConverter.GetConverterFriendlyBaseType]`; Defer multi-argument parameter parsing to the base implementation * `IArgumentConverter.GetConverterFriendlyBaseType`; Theoretically better support multi-argument parameters with slash registration * Update deps * Resolve 1 nullable warning * Fix logic within user command registration, no longer allowing it to be forever false * Remove old event registration logic * Expose `IServiceProvider` instead of pointlessly hiding it * Switch from `AsyncEventArgs` to `DiscordEventArgs` * Move converter result values to their own namespace instead of repeatedly redeclaring on generic types * Remove ConverterFriendlySearchFlags; Add new `EnumConverter<T>`; Use the generic version of EnumConverter for parameters. * Fix compiler errors * Fix params registering all parameters as required * Fix choice providers not registering; Correctly isolated slash command logic away from the command parameter builder; Add an autocomplete provider for enums with more than 25 fields * Remove object constructors and replace them with more type-specific constructors for compile-time safety. * Vast improvements to the autocomplete and choice providers API - `SlashAutoCompleteProviderAttribute.AutoCompleteAsync` and `SlashChoiceProviderAttribute.GrabChoicesAsync` will now truncate when more than 25 elements are provided. - When options are truncated, it will log which source gave too many options, which it previous didn't. - When the type cannot be created, it will log which type failed along with the exception. - Try to use the numeric values for enums when possible, serializing only to `string` when the base type is `ulong`. - Support double and float enums, because apparently that's a thing? - Change the method signatures to return an enumerable of the object directly instead of dictionaries - Remove `SnakeCasedNameAttribute` in it's entirety, replacing it with `IParameterNamingPolicy`. * Fix compiler error * Expose the conversion result to `ArgumentParseException`; Documentation on related members. * Missed a spot * Fields to properties * Correctly apply limit * Just git- I mean get * Line feeds? * `git diff --name-only --diff-filter=AM master | grep ".cs" | xargs -I{line} echo \'{line}\' | xargs dotnet csharpier` * Update deps * Add generic overloads * Format code in docs * Grammar; New empty `T : new()` generic restraint on `AddConverter<T>()` * Update autocomplete/choice provider documentation * Update the missing slash commands section * Rename `DSharpPlus.Commands.Processors.SlashCommands.ParameterNamingPolicies` to `DSharpPlus.Commands.Processors.SlashCommands.NamingPolicies` * New `Naming Policies` article * Document multi-argument parameters * Don't throw when enums fail to convert * Support all time units from nanosecond to years * Give converters their own section; Briefly go over built-in argument converters and their quirks * Add a guide for invoking argument converters manually * Enforce max argument count in MAPs * Undo formatting from `dotnet csharpier` The new formatting now follows two very simply rules: - If it does not go beyond the end of my 1080p screen with the file bar open, it stays inlined. - If Roslyn didn't yell at me about it. * Allow 3rd party command processors to implement their own generic enum converter * Begone MAPs, welcome in VAPs * Remove raw numbers :( * Footnote * Formatting * #1362 was never merged * Throw away the rest of the MAPs * docs * Interface checks * Variadic * Attempt to resolve #1950 * Rename `ParameterNamingPolicy` to `NamingPolicy`; Fix inverted if statement * Use `GetCultureInfo` * More docs * Localizing interactions * Double space * Fix final GitHub review
* Oops! I sneezed. * One of you hooligans needs to fix your IDE formatting. `dotnet format` * Fix context menu processors requiring exact types instead of ish types * ConfigureCommands event from #1680 * Documentation; Changed equality implementation on `ConverterDelegateFactory`; Fixed runtime startup exceptions * Move `GetConverterFriendlyBaseType` to `IArgumentConverter` to prevent static implementation on every command processor * Several bug fixes to argument parsing and conversion logic - Finish moving `GetConverterFriendlyBaseType` - Prevent `AddConverter` from throwing when the same converter is attempting to be added again - Early return on `ParseParametersAsync` when no parameters need to be parsed - Move default value logic from `ParseParametersAsync` to `ParseParameterAsync` - `ParseParameterAsync` now provides the value that failed to parse when returning `ArgumentFailedConversionValue` - `ExecuteConverterAsync<T>` now handles multi-argument parameters * Shadow `InteractionConverterContext.Argument` so `ConverterContext.Argument` can still be the raw value * Fix enum parsing for text commands, which now properly supports boxing (is it called boxing?) * There can only be one reply to a Discord message * Defer multi-argument parameter parsing to the base implementation * Theoretically add support for `TextMessageReplyAttribute` to most argument converters * Use `IArgumentConverter.GetConverterFriendlyBaseType` * Configure commands event args. This is non-negotiable. * Use `IArgumentConverter.GetConverterFriendlyBaseType]`; Defer multi-argument parameter parsing to the base implementation * `IArgumentConverter.GetConverterFriendlyBaseType`; Theoretically better support multi-argument parameters with slash registration * Update deps * Resolve 1 nullable warning * Fix logic within user command registration, no longer allowing it to be forever false * Remove old event registration logic * Expose `IServiceProvider` instead of pointlessly hiding it * Switch from `AsyncEventArgs` to `DiscordEventArgs` * Move converter result values to their own namespace instead of repeatedly redeclaring on generic types * Remove ConverterFriendlySearchFlags; Add new `EnumConverter<T>`; Use the generic version of EnumConverter for parameters. * Fix compiler errors * Fix params registering all parameters as required * Fix choice providers not registering; Correctly isolated slash command logic away from the command parameter builder; Add an autocomplete provider for enums with more than 25 fields * Remove object constructors and replace them with more type-specific constructors for compile-time safety. * Vast improvements to the autocomplete and choice providers API - `SlashAutoCompleteProviderAttribute.AutoCompleteAsync` and `SlashChoiceProviderAttribute.GrabChoicesAsync` will now truncate when more than 25 elements are provided. - When options are truncated, it will log which source gave too many options, which it previous didn't. - When the type cannot be created, it will log which type failed along with the exception. - Try to use the numeric values for enums when possible, serializing only to `string` when the base type is `ulong`. - Support double and float enums, because apparently that's a thing? - Change the method signatures to return an enumerable of the object directly instead of dictionaries - Remove `SnakeCasedNameAttribute` in it's entirety, replacing it with `IParameterNamingPolicy`. * Fix compiler error * Expose the conversion result to `ArgumentParseException`; Documentation on related members. * Missed a spot * Fields to properties * Correctly apply limit * Just git- I mean get * Line feeds? * `git diff --name-only --diff-filter=AM master | grep ".cs" | xargs -I{line} echo \'{line}\' | xargs dotnet csharpier` * Update deps * Add generic overloads * Format code in docs * Grammar; New empty `T : new()` generic restraint on `AddConverter<T>()` * Update autocomplete/choice provider documentation * Update the missing slash commands section * Rename `DSharpPlus.Commands.Processors.SlashCommands.ParameterNamingPolicies` to `DSharpPlus.Commands.Processors.SlashCommands.NamingPolicies` * New `Naming Policies` article * Document multi-argument parameters * Don't throw when enums fail to convert * Support all time units from nanosecond to years * Give converters their own section; Briefly go over built-in argument converters and their quirks * Add a guide for invoking argument converters manually * Enforce max argument count in MAPs * Undo formatting from `dotnet csharpier` The new formatting now follows two very simply rules: - If it does not go beyond the end of my 1080p screen with the file bar open, it stays inlined. - If Roslyn didn't yell at me about it. * Allow 3rd party command processors to implement their own generic enum converter * Begone MAPs, welcome in VAPs * Remove raw numbers :( * Footnote * Formatting * #1362 was never merged * Throw away the rest of the MAPs * docs * Interface checks * Variadic * Attempt to resolve #1950 * Rename `ParameterNamingPolicy` to `NamingPolicy`; Fix inverted if statement * Use `GetCultureInfo` * More docs * Localizing interactions * Double space * Fix final GitHub review
Summary
At the moment, both CommandsNext and SlashCommands are relatively unmaintained while containing a lot of... unoptimized code. Additionally, having these packages separate will force the consuming user to choose between text commands or interactions. This extension unifies all command frontends through command processors.
Requirements
Roadmap
Notes
Light testing has been done and core functionality is guaranteed, however more thorough testing is required.