Idea: extensibility

[jods4]

Hi @ipjohnson !

I'm watching this repository with interest, as someone who has built my own attribute-based registration for DryIoC (to replace what Grace had).
Many people use MS DI (as it is the default) and this library will be fantastic for them.

It would be interesting to come up with an extensibility story. I know it's a big ask and I'm not quite sure how that would work in practice. Extensibility is a lot easier at runtime, for a code generator I suppose we would need a way to register additional attributes and build-time code that generates code fragments?

Here are two categories of use-cases that need extensibility:

1. More complex registration rules

Examples from my projects:

We use Refit to generate http clients from interfaces, with a dedicated [ExportApi] attribute.
The gist of it is to register a factory that is type-dependent
ctx => Refit.RestService.For(attributedType, ctx.Resolve<HttpClient>(serviceKey: httpClientName))
Note how the factory depends on attributedType and httpClientName, which are properties of the specific attribute instance.

Another example is conditional exports: we have [ExportIf(environment)] and [ExportIf(configuration)] that basically wrap the registration in a if statement that checks the current environment or a specific configuration key.

2. Provider-specific options

One motivation for using a different DI provider is access to additional features.

In my projects we use attributes to register services with:

• (Typed) metadata (DryIoC and Grace)
• Single instance registration for multiple interfaces (container.RegisterMapping in DryIoC)
• Priority (in Grace)