Skip to content

Conversation

@OoLunar
Copy link
Contributor

@OoLunar OoLunar commented Nov 12, 2023

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

Feature Currently Supported
Text Commands Yes
Slash Commands Yes
Command Aliases Text Commands
Generated Aliases No
Command Groups Yes
Custom Argument Type Converters Yes
Per Argument Type Converters Yes*
Built In Help Command No
Params (Auto Generated Arguments) Yes
XML Documentation No
Translation Classes Yes
Pre-Execution Checks Yes

Notes

Light testing has been done and core functionality is guaranteed, however more thorough testing is required.

@akiraveliara
Copy link
Member

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 UseCommandsNext and UseSlashCommands as obsolete, for removal sometime in the v5 cycle; either in 5.0 if it takes a while, or in a following minor release.

@OoLunar
Copy link
Contributor Author

OoLunar commented Nov 12, 2023

Because the rest of DSharpPlus is on .NET 7, I've chosen to keep CNext and Slashies not obsolete until .NET 8 releases

@akiraveliara
Copy link
Member

that'll be in a few days, and probably before merging this PR

@OoLunar
Copy link
Contributor Author

OoLunar commented Nov 12, 2023

Done

@OoLunar OoLunar changed the title Add new extension: CommandAll Add new extension: DSharpPlus.Commands Nov 12, 2023
@inftord
Copy link
Member

inftord commented Nov 13, 2023

Before any documentation work happens, i would suggest to archive old command articles, instead of removing them completely

Copy link
Member

@akiraveliara akiraveliara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overarching points:

  1. consider renaming DSharpPlus.Commands.Commands. since it mostly deals with construction of a command tree; DSharpPlus.Commands.Trees? Done - Lunar
  2. i really don't like multiple types in one file, it makes it harder to find these types later
  3. what exactly is the DX for configuring different processors? this seems a little doubtful given the implementation, but maybe you have a solution
  4. attributes should never contain logic, and much less throw exceptions. i believe @Instellate had a good design for checks in #1553
  5. 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.


public interface IArgumentConverter<TEventArgs, TOutput> : IArgumentConverter where TEventArgs : AsyncEventArgs
{
public Task<Optional<TOutput>> ConvertAsync(ConverterContext context, TEventArgs eventArgs);
Copy link
Contributor Author

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?

@OoLunar
Copy link
Contributor Author

OoLunar commented Nov 14, 2023

what exactly is the DX for configuring different processors? this seems a little doubtful given the implementation, but maybe you have a solution

What do you mean by DX?

@akiraveliara
Copy link
Member

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.
Copy link
Member

@Plerx2493 Plerx2493 Nov 14, 2023

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

Copy link
Contributor Author

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)
Copy link
Member

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.
Copy link
Member

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

Copy link
Member

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)
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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

Copy link
Contributor Author

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

@OoLunar OoLunar mentioned this pull request Nov 15, 2023
@OoLunar OoLunar marked this pull request as ready for review January 30, 2024 15:37
@OoLunar
Copy link
Contributor Author

OoLunar commented Jan 30, 2024

All changes and review comments will be moved into issues as we need to start receiving user feedback soon. Merging into nightlies.

@akiraveliara
Copy link
Member

i'll take a cursory look for intolerable flaws and then sign off on this

@akiraveliara
Copy link
Member

:shipit:

@akiraveliara akiraveliara self-requested a review January 30, 2024 15:44
Copy link
Member

@inftord inftord left a 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!

@OoLunar OoLunar merged commit 8f0f9a8 into DSharpPlus:master Jan 30, 2024
OoLunar added a commit that referenced this pull request Sep 25, 2024
OoLunar added a commit that referenced this pull request Oct 3, 2024
OoLunar added a commit that referenced this pull request Oct 3, 2024
OoLunar added a commit that referenced this pull request Oct 3, 2024
OoLunar added a commit that referenced this pull request Oct 3, 2024
akiraveliara pushed a commit that referenced this pull request Oct 6, 2024
* 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
Instellate pushed a commit that referenced this pull request Nov 4, 2024
* 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
@akiraveliara akiraveliara mentioned this pull request Nov 26, 2024
20 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants