I am leaning towards re-implementing my dynamic proxy as open source (BSD license of course).
As with any open source project my biggest problem was not a shortage of ideas but in finding a really cool name that I could also have the domain for :) In this process I have come across something odd. In AOP Ido not actually use dynamic proxies! I use Dynamic Decorators.
Proxy 
Decorator 
from http://www.nku.edu/~hauserj/Structural%20Pattern%20Summary.ppt
- The Proxy Pattern is similar in structure to the Decorator Pattern.
- Both describe how to provide a level of indirection to an object.
- Both keep a reference to another object to which requests are forwarded.
- The difference again is the intent.
- Like the Decorator, the Proxy composes an object and provides an identical interface to clients.
- Unlike the Decorator, the Proxy
- Does not attach and detach properties dynamically
- Is not designed for recursive composition.
- The intent of the Proxy is to stand in for a subject when it is inconvenient or undesirable to access the subject directly.
- Ie the subject may reside on a remote machine or have restricted access.
- In the Proxy pattern, the subject defines the key functionality and the proxy provides or refuses access to it.
- In the Decorator, the component provides a subset of the functionality and the decorators provide the rest.
- The Decorator addresses the situation where the objects totally functionality may need to be determined at run-time.
- The Proxy focuses on the relationship between the proxy and its subject which can be expressed statically.
- The differences between the Proxy and Decorator Pattern are significant but that does not mean they can not be combined.
- A Proxy-decorator might add functionality to a proxy
- A Decorator-proxy might embellish a remote object.
It sure seems to me that what we are actually using is a dynamic decorator not a dynamic proxy in the first place. I mean we are explicitly adding functionality to the object (aspects) at run time.
I think the key item in the list is
“The Decorator addresses the situation where the objects totally functionality may need to be determined at run-time.”
This is absolutely the case when we are dealing with aspects.
One major problem I see with using true decorators is the subject setter, I currently don't use it and I cannot in my mind come with anyway that I could possible use it.
In order for me to be able to use an instance setter I would need to cast the proxy to another type in order to be able to access it. This in my mind removes the transparency of the proxy itself. I should never have code that does something along the lines of
Foo foo = new Foo();
IProxy fooproxy = ProxyFactory.CreateProxy(typeof(Foo));
fooproxy.SetInstance(foo);
because I am now readily aware that I am not dealing with the original type. I preferred instead to make my objects immutable as I never really saw them being reused anyways.
That being said, because I am not using an instance setter, am I actually using a decorator pattern?! One of the key points of the decorator pattern is the instance setter that allows for multiple subjects through out the lifespan of the instance. Am I actually generating some weird form of hybrid between a proxy and a decorater (a decoroxy perhaps) .
Anyways I was able to register the domain DynamicDecorator.com and .net so I am happy :)
I am considerring some other changes to the ways I was doing things as I move things to OS. One thought that I have been mulling over for quite some time now is that the dynamic aggregation part used in mixins is useful on its own, perhaps I should actually pull that out into its own factory and pull the decoroxying out into its own factory then provide a service which combines the two.
Pros:
More reusable
Clearer / vastly simplifies the code
Better seperation of concerns
Cons
Two types instead of one
Probably a bit slower
Thoughts?