You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some attributes are going to be needed for arguments. Some I can think of, off the top of my head are:
[Rest] simple really, used along side any type, everything after would be parsed as that type (i.e. a command of int, [rest] user would parse a single int, and infinite users (up to the amount provided)
[Range(int min, int max)] specify a range for arguments. How do we give this to a resolver? How about custom types - i.e. datetime? Do we use an object? We don't have generic attributes yet...
[ExecutingMessage] when paired along with an argument of type Message, it informs the handler that actually, we want the messaged used to execute the command - NOT a supplied message.
[Precondition(Type conditionType)] this is an interesting one. We could in theory have preconditions for argument parsers - maybe even ones that take in functions. This could allow for finer control over how the argument is handled, outside of the command (i.e. you could make one that doesn't even bother running the command if the Users' name begins with a 'T')
Happy if anyone can suggest anymore - these are the most useful I see now, however.
The text was updated successfully, but these errors were encountered:
Some attributes are going to be needed for arguments. Some I can think of, off the top of my head are:
[Rest]
simple really, used along side any type, everything after would be parsed as that type (i.e. a command ofint, [rest] user
would parse a single int, and infinite users (up to the amount provided)[Range(int min, int max)]
specify a range for arguments. How do we give this to a resolver? How about custom types - i.e. datetime? Do we use an object? We don't have generic attributes yet...[ExecutingMessage]
when paired along with an argument of type Message, it informs the handler that actually, we want the messaged used to execute the command - NOT a supplied message.[Precondition(Type conditionType)]
this is an interesting one. We could in theory have preconditions for argument parsers - maybe even ones that take in functions. This could allow for finer control over how the argument is handled, outside of the command (i.e. you could make one that doesn't even bother running the command if the Users' name begins with a 'T')Happy if anyone can suggest anymore - these are the most useful I see now, however.
The text was updated successfully, but these errors were encountered: