Less fun with delegates
Earlier this year I did a post thinking about ways to use delegates. I have also boldly said that I thought it might be possible to use delegates to accomplish some of what is done with AOP without having to make the pretty painful choice between existing implementations that are currently available for .net. Over the last few weeks I have been dabbling with some of these ideas. Programming is hard......
The test was to create a class that has methods and property accessors whose external interface is completely implemented by delegates. I had the additional requirement that all the code I wrote looked consistent enough so that it could be written by a generator. Actually, this requirement came later when I started realizing what a pain in the butt my code was beginning to look like and how embarrassing it would be to tell somebody to code that way. Anyway, I plowed ahead. Part of the motivation was the result of reading the post and long string of comments by Mats Helander. So, somebody sets a property and without having to manually code an ugly sort thing like what Mats demonstrated in his blog, they instead had to do the ugly sort of thing in my test code. Anything, not just a persistence engine, that wanted to know about the property change would know, AND the property would get changed. This would be a join point in AOP terms I think, and on the surface the delegate looked like a nice idea. But then the actual coding started.
public string AProperty {
get {return theAPropertyGetDelegate();}
}
This could be so simple. It works for returning a property right? Not right as I'm sure some of you smart people figured out already. First of all, a multicast delegate might allow multiple methods to get fired. Which one gets to set the return value of the property? There are ways around that though. More important though, a join point would have features like firing before the property access, after the access, on the return value, and in all of these options, there might be a reference to the context of the caller, callee or framework. A delegate can only have one signature.
Sigh.. So inherit from MulticastDelegate. MulticastDelegate is a “special class” that can't be inherited from.
Sigh.... So inherit from a delegate created by the delegate keyword!! A delegate created by the delegate keyword is sealed
Sigh..... So know, I'm left with writing my own command objects from scratch, and then having to force the user to write in a way that is not POCO at all
SIGH>>> Well, I haven't given up yet. With generated code there might still be hope. But now I'm just at the point of creating command objects. A framework would have created a subclass or decorator instead unless it's a IL ripper upper kind of thing. That is still a possibility but then the POCO story gets more complicated because of requirements of default constructors which I generally don't like because they leave your objects in an essentially inconsistent and easy to break state, not to mention having to make all methods virtual.
Who knows, maybe by the time I figure out a solution I can live with, a production ready AOP framework that somehow is compatible with my last three years of work will come on the scene! Or not.