AddModuleAsync/AddModulesAsync should not require an IServiceProvider
If one is not passed, they will default to an EmptyServiceProvider This resolves issues where since the merging of OnModuleBuilding, users were effectively forced to use the DI pattern, where before they were not. While this isn't necessarily a bad idea, we shouldn't just change this behavior for no reason (though I assume making the IServiceProvider argument required was a mistake)
This commit is contained in:
@@ -95,9 +95,11 @@ namespace Discord.Commands
|
||||
_moduleLock.Release();
|
||||
}
|
||||
}
|
||||
public Task<ModuleInfo> AddModuleAsync<T>(IServiceProvider services) => AddModuleAsync(typeof(T), services);
|
||||
public async Task<ModuleInfo> AddModuleAsync(Type type, IServiceProvider services)
|
||||
public Task<ModuleInfo> AddModuleAsync<T>(IServiceProvider services = null) => AddModuleAsync(typeof(T), services);
|
||||
public async Task<ModuleInfo> AddModuleAsync(Type type, IServiceProvider services = null)
|
||||
{
|
||||
services = services ?? EmptyServiceProvider.Instance;
|
||||
|
||||
await _moduleLock.WaitAsync().ConfigureAwait(false);
|
||||
try
|
||||
{
|
||||
@@ -120,8 +122,10 @@ namespace Discord.Commands
|
||||
_moduleLock.Release();
|
||||
}
|
||||
}
|
||||
public async Task<IEnumerable<ModuleInfo>> AddModulesAsync(Assembly assembly, IServiceProvider services)
|
||||
public async Task<IEnumerable<ModuleInfo>> AddModulesAsync(Assembly assembly, IServiceProvider services = null)
|
||||
{
|
||||
services = services ?? EmptyServiceProvider.Instance;
|
||||
|
||||
await _moduleLock.WaitAsync().ConfigureAwait(false);
|
||||
try
|
||||
{
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
using System;
|
||||
using System;
|
||||
using System.Collections.Generic;
|
||||
using System.Linq;
|
||||
using System.Reflection;
|
||||
|
||||
Reference in New Issue
Block a user