* Apply consistency to attributes in the commands extension
This resolves#527.
Not sure if I missed any, putting this up for review.
* Allow preconditions to be used multiple times (for use with groups)
* Improve Boolean Property Summaries
Having the `CaseSensitiveCommands` property summary asking a question whenever Intellisense is invoked seems a bit nonessential instead of *properly* explaining what exactly it does. It would be better if instead, it stated it's use to be more comprehensible to the reader.
### Changes
- Edits the summaries of `CaseSensitiveCommands` and `ThrowOnError` to follow a more methodical convention for boolean property summaries (`Determines whether X ...` rather than `Should X be ... ?`).
This is just a small change to improve upon the current documentation, so it shouldn't conflict with anything.
* "DefaultRunMode should also be "Gets or sets blah blah blah" to be consistent."
* Add NullableTypeReader.
Primitives now also load a NullableTypeReader<T> and any value types that get a typereader added will also have a NullableTypeReader<T> added for it.
* Remove unnecessary null check.
* Added docstrings.
* Allow commands to return a Task<RuntimeResult>
This allows bot developers to centralize command result logic by
using result data whether the command as successful or not.
Example usage:
```csharp
var _result = await Commands.ExecuteAsync(context, argPos);
if (_result is RuntimeResult result)
{
await message.Channel.SendMessageAsync(result.Reason);
}
else if (!_result.IsSuccess)
{
// Previous error handling
}
```
The RuntimeResult class can be subclassed too, for example:
```csharp
var _result = await Commands.ExecuteAsync(context, argPos);
if (_result is MySubclassedResult result)
{
var builder = new EmbedBuilder();
for (var pair in result.Data)
{
builder.AddField(pair.Key, pair.Value, true);
}
await message.Channel.SendMessageAsync("", embed: builder);
}
else if (_result is RuntimeResult result)
{
await message.Channel.SendMessageAsync(result.Reason);
}
else if (!_result.IsSuccess)
{
// Previous error handling
}
```
* Make RuntimeResult's ctor protected
* Make RuntimeResult abstract
It never really made sense to have it instantiable in the first place,
frankly.
* Allow arbitrary attributes to be added to commands
I still don't approve adding type info back into commands, so
I decided to use this solution for allowing arbitrary attributes to be
added to commands.
Add attributes property to ParameterBuilder
Add Attributes properties to info types
* Why on earth git
* Add using for system so that Attribute can be used
* C#7 features in commands, CommandInfo in ModuleBase
* Update TypeReaders with C#7 features and IServiceProvider
* Add best-choice command selection to CommandService
* Normalize type reader scores correctly
* Fix logic error and rebase onto dev
* Change GetMethod for SetMethod in ReflectionUtils
Should be checking against setters, not getters
* Ensure args/params scores do not overwhelm Priority
* Remove possibility of NaNs
* Add grouping of preconditions to allow for flexible precondition logic.
* Fix checking Module Preconditions twice (and none of the command's own)
* Fix command preconditions group 0 looping over every other precondition anyway #whoopsies
* Use custom message when a non-zero Precondition Group fails.
* Fix doc comment rendering.
* Refactor loops into local function
* Considering a new result type
* Switch to IReadOnlyCollection<T> and fix compiler errors
* Revert PreconditionResult -> IResult in return types - Change PreconditionResult to a class that PreconditionGroupResult inherits.
* Feedback on property name.
* Change grouping type int -> string
* Explicitly use an ordinal StringComparer
* Full stops on error messages
* Remove some sillyness.
* Remove unneeded using.
Parameter preconditions were always getting the empty service provider,
even when a custom one was provided in ExecuteAsync, which means that
preconditions which use services cannot work properly.
