This post originated from an RSS feed registered with .NET Buzz
by Jonathan Crossland.
Original Post: I support AOP not AOP stupid
Feed Title: Jonathan Crossland Weblog
Feed URL: http://www.jonathancrossland.com/syndication.axd
Feed Description: Design, Frameworks, Patterns and Idioms
The can of worms are wriggling on the floor.
I am tremendously happy that Eric has brought AOP up again.
I felt a bit silly (stupid really), going on For and Against AOP, so I thought I'd explain.
I believe that AOP is a fine education, but not mainstream.
I believe in AOP, but I dont. I do not like the weaving of code in and out of my code, not knowing what is going on. The compiler would also have to change its spots.
I would not like to see language changes like aspect, pointcut, in AspectJ over designed and too complicated for limited benefit.
But I have been advocating a form of it for a long time. Read here, here and here, here and here.
MTS (I believe Pat Helland was significant) and COM+, gave us a higher power.
From roles, transactions and sheer delight, I wrote my first book, Windows DNA with many other great people.
I truly believed that the world was getting better.
With Reflection, CodeDOM and more it was for a while, until ContextBoundObject deflated my dreams by making me a plumber - again.
I dont want to see the code weaving, static or dynamic, but I do want to snapin, observe and intervene.
Good reasons for "hooking in", "intervention", "AOP-like behaviour" are for
Structural Architectural elements - such as logging, exception management, security, roles, customizations based on roles etc.
The key though is that everything that we dont actually want to see entangled with the normal logic of the code exists out of sight.
Further, the Factory Method, Singleton and Observer patterns are in my opinion (at the top of my head), candidates for moving down lower into the plumbing.
How far? probably not compiler level, although the compiler might need to set it up correctly on the plate for the Runtime.
As I mentioned in a comment on Eric's post, I like an Intervention philosophy.
Code is sometimes better to illustrate so here is my attempt at some of the syntax.
notes on the psuedo code below,
If no Attribute is found then no overhead is incurred. Nothing happens
No ContextBoundObject to derive from.
I can hook in, from inside my Assembly (MyObject), or outside (MyOtherObject)
I believe that intervention, could be done in the compiler by altering the Symbol Graph, and by altering the current ContextBoundObject behaviour currently in the framework.
using System; using System.Runtime.CompilerServices; using System.Runtime.Intervention;
   //I can override members on IMessageSink if I desire (ie. Pre/PostProcessMessage)
   
   //gets sets and instance of - I can alter if I wish
   publicobject GetInstance (ObjectContext ctx){}    publicobject SetInstance (ObjectContext ctx){}