Eric asks here what scenarios would AOP encapsulate for us and would be useful for us. Here are a few I can think of:

·         Automatic Transaction, pooling declaration (see EntrepriseServices)

·         Automatic Object relocation (see remoting, but think message pipe)

·         Logging certainly

·         An alternative to code injection and hooks (that WILL be required at some point or another, windows have it, and there’s no other way to put a compatibility layer on compiled files)

·         Viewable: Let’s add behavior to a method when it can be called from WMI for example.

Are these doable without AOP support? Yes, by using two main patterns:

·         Context Bound Objects and sinks: Suffers from the loss of garbage collector in IPC and cross appdomains configuration (frankly, a domain where the Microsoft story is just plain bad)

·         Providing an architecture and using reflection: doable, but then you need to:

o       Standardize on a constructor pattern, such as abstract factories. Means changing an API, ok for new code like indigo, sucks for old code.

o       Rewrite code and recompile, which means AOP modules can’t be swapped at deployment time without recompilation.

The main tenant of AOP is to be able to NOT couple the aspect and the code. If you do couple, then CBO is ok (if someone can get cbrumme to launch a project for a faster tp creation, correct the distributed garbage collection across processes and appdomains on a single machine), and the custom construction patterns is fine. If not, then you can’t do much…

I have to agree with Cyrus on that one… I fell in love with this comedian a few weeks ago, with the sexy show… It is so damn fantastic.

And notice how when he dresses up as a woman, he’s neither man nor woman, can’t call it a drag queen or a proper transvestite either… He’s redefining it by wearing heels. That’s what I call a genius! 

(This post has been done off line and its delivery may be delayed.)

As I was reading Cyrus’ comments on embedding IDE editors in visual studio, and the realm of domain specific languages, it reminds me of the discussion I had with Richard about the IDE Future. Just thought I would get this back on the front line J 

Blog offline, this post delivery might be delayed.