From Wes Haggard:
"There has been a lot of concern and questions about whether or not we should use attributes as our programming model however we feel it makes for a nice declarative model. That said, keep in mind that just because attributes are the default programming model it does not mean it is the only possible programming model. We feel that there are enough extensibility points in the system to actually create any number of programming models, including the popular DI style XML configuration model. We are looking into either shipping or at least providing samples of other such programming models."

Could the current extensibility mechanisms allow the creation of an Aspect-Oriented Programming model, with Imports (Joinpoints), Exports (Advices) & 'Binding Rules' (Pointcuts) on top of the CompositionContainer?

Very interesting idea however I think that is stretching it a little too far :).

I'm no experton AOP but as I understand it a joinpoint is usually some place in the flow of execution (i.e. it is a place you want to inject new code to execute). Tracing is acanonical examplewheretracing code would be injected at thebegin and end of a method.

Our composition system is about injecting dependencies by setting values viafields, properties,or perhaps constructor arguments, not by injecting IL in random places.

Sorry but I think AOP is beyond what we are trying to solve with MEF.

---

Blog: http://weblogs.asp.net/whaggard

Very interesting idea however I think that is stretching it a little too far :).

I'm no experton AOP but as I understand it a joinpoint is usually some place in the flow of execution (i.e. it is a place you want to inject new code to execute). Tracing is acanonical examplewheretracing code would be injected at thebegin and end of a method.

Our composition system is about injecting dependencies by setting values viafields, properties,or perhaps constructor arguments, not by injecting IL in random places.

Sorry but I think AOP is beyond what we are trying to solve with MEF.

---

Blog: http://weblogs.asp.net/whaggard

Actually, I was thinking about Imports as a kind of pre-defined Joinpoints = Extensibility points (-> IL not injected at random places), and 'Binding Rules' as an additional level of granularity for the matching process, above the default matching based on Concrete & Duck types.

But you're right ;o) After I got the answer from Dave, describing the possibility of using Metadata to be consumed by the import, allowing it to filter exports, I indeed thought that my post about AOP was maybe a little bit 'off topic' lol ... Although, I'm not sure yet if the responsibility to filter Exports based on Metadata should be done by the Import itself, the ValueResolver or a class in between (see ComponentModel Contributors/Inspectors in Castle Windsor).

So indeed, I guess that a full AOP implementation is most probably not necessary but some AOP-like feature, e.g. Interceptors (in Castle Windsor), might be nice to have, to allow developers to easily apply cross-cutting concern code between an import and its matched exports. ;o)

Btw, it's also possible to 'emulate' a simple AOP programming style with Decorators & Chains of responsibilities, which should pose no problem for the CompositionContainer, as they usually rely on interfaces.