Resolve #11: Use Func<X, Y> to handle methods with parameters. #12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added the test for #11 and, for the case of methods with generic parameters, switched the
ResolvingInterceptor
to dynamically create aFunc<X, Y>
delegate type based on the parameter types and return type for the method, then use that resolved factory for the method backing.The biggest challenge around generic parameters is that, while you might have
OpenGenericImpl<string>
as a parameter, someone could also dopublic class MyClosed : OpenGenericImpl<string>
and pass one of those as the parameter, so you get into type casting and compatibility challenges... which we've already solved in core Autofac. Hence the desire to reuse that logic and not mirror it here.I didn't add caching for the
Func<X, Y>
type signature; we'd need to add method caching and matching logic something similar to the constructor caching and matching in core Autofac which seemed a little overkill here. It does mean for every method invocation (for methods with generic parameters) it's two resolution calls - one to get the factory, one to get the resolved object. Not sure if that's acceptable, but it seemed the simplest way to add support to for open generic methods/parameters.I did leave the original logic for methods that don't have generic parameters so it's still reasonably optimal.
Generic return types don't appear to have any impact here, so there was no special requirement or change to handle that.