Skip to content
This repository has been archived by the owner on Mar 13, 2023. It is now read-only.

[FEAT] Ensure consistency between all methods to define application commands #390

Closed
4 tasks
artem30801 opened this issue Mar 15, 2022 · 2 comments
Closed
4 tasks
Labels
Help wanted More people are wanted to help with this Improvement Something that is already implemented but can be done better
Milestone

Comments

@artem30801
Copy link
Contributor

artem30801 commented Mar 15, 2022

Is your feature request related to a problem? Please describe.
I'm always frustrated when inconsistency

Describe the solution you'd like

All methods to define application commands should have consistent signatures - same args, same type hinting, same defaults. Functions, decorators, class methods, class inits, all of them. Same goes to slash command options and their definition methods

Tasks:

  • consistent args and kwargs (presence, names, order)
  • consistent type hinting
  • consistent defaults
  • double check usage of None, MISSING in defaults and Absent vs Optional type hints
@artem30801 artem30801 added Improvement Something that is already implemented but can be done better Help wanted More people are wanted to help with this labels Mar 15, 2022
@artem30801 artem30801 added this to the Beta milestone Mar 15, 2022
@LordOfPolls
Copy link
Member

So - taking this issue literally, i disagree with the premise All methods to define application commands should have consistent signatures - same args, same type hinting, same defaults

if we look at the methods to instantiate a app command we have

  • @slash_command
  • @subcommand
  • class SlashCommand
  • SlashCommand.subcommand

Going one by one;

  • @slash_command being the recommended to make a non-sub app command. Its type hints are weird, they should be fixed.
  • @sub_command as per its docstring, is inteded to be an alternate way to define a slash command, specifically for sub commands. It was also requested. By its very purpose it should NOT have the same signature as @slash_command
  • SlashCommand.subcommand is the alternate to @sub_command- which creates a subcommand from an existing command, as it is creating a command based off of another, there are certain fields it should not have. Again meaning it shouldnt share a signature
  • class SlashCommand being the last suppported way to create a command, isnt really an recommended way to define commands, its designed to act as a model, not a construction vector. By its very purpose, it shouldnt mirror the type hints nor signature of the decors as its use case would be completely different.

I'll admit work could be done to ensure the resultant command object has the same defaults between them, but a blanket all signatures should be the same is asinine and defeats the purpose of having multiple methods. They are literally not supposed to be the same

If ive missunderstood, please correct me.

@LordOfPolls
Copy link
Member

Closing due to inactivity

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Help wanted More people are wanted to help with this Improvement Something that is already implemented but can be done better
Projects
None yet
Development

No branches or pull requests

2 participants