[Question] Using options pattern for DiscordHostConfigurationBuilder

[Pyrobolser]

Hello,

I was wondering if we could replace the DiscordHostConfiguration a class that implements IOption like explained here in the documentation?
What is your opinion on this?

Thanks for your work on this hosting add-on, it makes everything cleaner and it's a good experience to study to understand how all the inner cogs are working together!

[Hawxy]

Hey, thanks for the suggestion. Usage of the Options library hadn't really crossed my mind. I'll take a look at this as soon as I can.

[Hawxy]

@Pyrobolser Do you have a functional scenario that you'd find this useful in? The Options Library is helpful for situations where you have a lot of configuration settings & advanced requirements like change notifications. This project has neither. I also don't know any *.Hosting extension libraries that use it outside of Microsoft's Azure ones.

Using it would certainly save me a few lines of code,, but I could also save most of those lines just by moving back to configuring the class directly instead of going through a builder.

I could maybe see this being useful if you were using ASP.NET Core and wanted to configure things via DI extensions, but again I could achieve that just be splitting the DI stuff from the HostBuilderExtensions.

[Pyrobolser]

I confess that I didn't really took into account the fact that you're a *.Hosting extension library when I asked my question.
When adding my own services to my apps I liked being able to just do

services.Configure<MyServiceOptions>(Configuration.GetSection("MyService"));

and let the binding and validation happen behind the scene, but I suppose that's what you mean by "moving back to configuring the class directly instead of going through a builder".
I think I need to read more about why using a builder like you did, instead of going without it. In the end, it's probably not that crazy of a difference.

Thanks for your answer.

[Hawxy]

The builder pattern is pretty common for configuring DI/Host extensions for one of two reasons:

1. The underlying library already contains a configuration builder and thus the extension naturally exposes it.
2. It reduces the mental load for the user by consolidating configuration to the same location as the DI registration and makes it less likely that the user will configure something incorrectly by making it obvious what should be configured.

In our scenario we're the latter, although the builder is definitely overkill and just exists because it makes configuration minutely cleaner.

As part of the next semver major release, I could make the HostBuilderExtension config optional and use IOption<T> internally so users can call services.Configure<T>() themselves if they really want to. The Azure libraries effectively do the same thing.