AOP/Partial classes/code generation?

Jimmy writes a post that just happens to nick something I've been working on myself. Yes the problems that AOP tries to solve are worth solving and are really hard to solve using traditional techniques. This is especially true if you take “traditional techniques” to mean ordinary approaches to OO development where code sharing is only possible via inheritance or to a lesser degree via composition if anybody actually taught that sort of thing. I recently noticed that a completely new way of doing AOP in .net was being done by the AspectDNG group much more similar to how some of the java approaches have worked. Still, even though ripping apart assemblies and piecing them back together again could only be described as cool, as Chad who I work with pointed out, debugging would have to be really hard even if the framework were really solid. Maybe not, but only some real experimentation would answer that. Somewhere though, I keep thinking that there are approaches possible with the existing codebase.

This week and last I have been experimenting with code generation. Jimmy refers to the partial class technology that is supposed to be part of vs.net 2005. Basically as I understand it it just allows you to inject source from multiple places into a single compilation unit. It may be very elegantly done and the approaches I have been working with fall somewhat short of elegant. Still, the idea that source can be assembled at compile time is OLD stuff even if the tools have not advanced as far as we would like. It makes me think back to my early programmer days where is was a very common thing to write code in perl that wrote code that was then executed. Perl is an enormously successful text processing language and I have encountered very few new ideas in macros, code gen, string processing, file manipulation and dynamic compilation that weren't already there in perl in 1998. Some of my recent code gen work has been with CodeSmith. It is very safe to say that compared to perl, CodeSmith looks like vb6 to a java programmer. But it does save needing to write some of the vs.net addin stuff I would also really like to have. It will probably be some time until I get to digest the possibilities that partial classes have to offer so in the meantime normal string processing in c# and template processing with CodeSmith looks like the ticket.

What I have been trying to do is to prove, to myself anyway, that it's possible to do much of what O/R mappers do without that pesky dependence on a database, and without so much coding. At the same time I am digging into O/R mapping tools trying to see how they solve certain types of problems. As Jimmy points out from our meeting in Malmo, Rickard showed that much more was possible with AOP than the intro examples we have been seeing. Ever since then, I have been pondering ways to accomplish much of the same without an AOP framework, since such a thing in .net seemed a long way off. So, it would appear I'm trying to avoid O/R mappers and AOP. Luddite? Conservative? Since I haven't put nearly enough time into either of these efforts, perhaps either is appropriate, but I sure hope not. The overwhelming sense I keep coming back to is this: ITS JUST GOT BE EASIER THAN THIS!

Here's to new ideas.....