Expose configuredParameters and configuredProperties from the ReflectionActivator

[GoogleCodeExporter]

Currently if you want to wrap/modify ReflectionActivator for some type, you 
can't access parameters and properties that were specified when the 
registration was made.

Use case would be a module that wants to AttachToComponentRegistration and 
read/modify/affect the registration in some way that requires this information.

Suggested solution:
ReflectionActivator should expose configuredParameters and configuredProperties 
as public properties.

Original issue reported on code.google.com by ashm...@gmail.com on 12 Nov 2013 at 8:04

[GoogleCodeExporter]

Original comment by travis.illig on 14 Nov 2013 at 4:30

• Added labels: Module-Core, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

While I can see the use case as described, there are a few challenges with the 
suggested design that break the abstractions provided by the framework.

The primary is that the AttachToComponentRegistration (or anything else 
planning to use this mechanism) would have to "know" about the type of 
IInstanceActivator getting registered for each type. We have more than just 
reflection - there's one for provided instances and one for lambdas, for 
example. That pretty closely ties any logic wishing to use the feature (like 
the configuration module) to "knowing" about how the registrations are made. 
It's not an optimal design to cross that intentional separation.

If you need to change which parameters are configured for a registration, one 
way to do that is to switch how the registration gets made. For example, if you 
need to change some value based on configuration, instead of registering the 
component by itself and then retroactively changing the value later, you might 
do the conditional parameter registration up front or consider using a lambda 
registration rather than a reflection-based registration.

Alternatively, if you have more than one registration for the same type and you 
need different parameters based on context, you might consider either using our 
attributed-metadata extensions or possibly using the Func<T> relationship we 
provide.

Given there are potentially other ways to achieve the desired functionality and 
there are risks with exposing (and, later, maintaining) this as a "supported 
piece of the API," I think we'll probably pass on this for now and keep a watch 
for other requests for the same feature. If it turns out to be popular, perhaps 
we can revisit it in a way that maintains the abstraction.

Original comment by travis.illig on 18 Nov 2013 at 9:28

• Changed state: WontFix

[GoogleCodeExporter]

Ok. I'll show you a more specific use case (similar to mine) -- maybe it can be 
solved without breaking the abstraction. Let's say you want to implement 
something like 
https://code.google.com/p/autofac/source/browse/Extras/Source/Autofac.Extras.Dyn
amicProxy2/RegistrationExtensions.cs, but as a module instead of registration 
extension (let's say you have some criteria so it is not for all types, but 
criteria are reusable and not tied to anything specific to a given application).

How would you do that?

Original comment by ashm...@gmail.com on 19 Nov 2013 at 1:06

[GoogleCodeExporter]

Off the top of my head, if I needed to do something like that I'd probably look 
at implementing a registration source rather than a module. That's how we 
"automatically" support things like collections - IEnumerable<T> when you 
register things of type T. The registration source handles returning the types 
and activation information about things that are "found in the container" on 
the fly.

However, this is probably a better question to ask on the newsgroup than to try 
and solve here. That would be a great place to explain in larger detail the use 
case you have in mind, get more ideas on how to solve the problem, and flesh 
out a design that will work for you. If it turns out in the forum that there 
really is no way to do what you're looking to do and it can be seen as a 
general purpose use case that we should support in the core framework, then we 
can reopen this issue or we can open a new one with information from the 
newsgroup.

You can visit the Autofac discussion group here: 
http://groups.google.com/group/autofac

Original comment by travis.illig on 19 Nov 2013 at 1:53