techno.blog("Dion")

“Pinocio” has spoken out against AOP in the mainstream. His comment is about the fact that OOP has isolation via classes, yet AOP does not. Aspects are not isolated from eachother, which can cause issues.

He brings up an important point… however I think that we will learn to deal with this issue. We can already harm ourselves (as we have done) via overuse of inheritance in OOP. The same is going to be the case in AOP. No-one in AOP is saying “aspects everywhere” or “this is the silver bullet”, even though the media sometimes makes this claim. AOP complements OOP. We have to learn HOW to use the power that we gain, and NOT overuse it. Unfortunately I am pretty sure that many people will go headlong into AOP and go crazy with aspects… and this will cause a lot of pain. We will do our best to reign this in as much as possible, but it will be a hard task. If we listen to the gurus in AOP then we will be OK. Listen to them, not the media (apart from TheServerSide of course ;)

Read Pinocio in “On fundamental AOP deficiency”

Rickard and Crazy Bob are having an interesting blog conversation about AOP and mixins. Rickard has recently enhanced his AOP framework to enable some form of static typing, to get around the loose typing that he had before. Now, he can place “implements Interface” on classes…. and instead of actually implementing them, his framework will take care of that.

This seems fairly similar to implementing interfaces in AspectJ, and having those interfaces actually have implementation code in them (yes, with AspectJ you can add concrete methods to Interface types!).

Very powerful stuff.

Read the blogs:

Rickard’s original post: AOP – dynamic and static at the same time!
Bob’s response: Rickard refines his AOP framework.
Rickard’s response to Bob’s response: AOP – abstract clarifications

Rickard has a blog entry “AOP – academic vs community” in which he notices that everyone and their auntie is creating a new language for AOP in the academic community.

Rickard seems to much prefer the “we can do this in Java” way of doing things. Althought I am sure that we won’t be using these languages in mainstream, this is what people do in academia isn’t it? They test boundaries, try out assumptions, etc.

I am personally interested in both: a) what cool AOP things we can do with our current languages, and b) what cool concepts *deserve* new keywords, and new constructs in a language. I have grown to like AspectJ, and think that if AOP hits off it will be natural to have a language like this.

Doesn’t it seem a little like going back in time when OOP started to develop. There were again lots of languages in academia, and “the real world” had many people saying “why not just use vtable dispatches?”, and then “let’s strap it on C [C++]“. Here we go again… lets see what happens when we jump off the round-a-bout.

AOP is getting more and more air time. There is an interesting thread that has sparked out of Bill Burkes Tech Talk on TheServerSide. Although it does tend to get a little personal (although hidden behind ;) and :)), it is good to read. I personally have bought more into the Gregor way of looking at AOP. It isn’t just interception :) I can understand Bill’s point, where he says that he starts off by talking about that with developers as they can “get it”, but they really do need to note that this is exactly what is being done.

Coming from the world of science, I totally get the idea of being told “this is the way it is”, and then a year later being told “you thought it was like that, now you can learn the way it really is”, and then the next year …

However, it has come across from some of the JBoss guys more like “no, AOP == Interception, don’t look further”. This is just wrong. People can delve into the world of AOP via JBossAOP and just use the semantics that they have available to them, that is fine. One of the things that I love about AOP is the fact that people can incrementally get into the technology.

Cameron called AOP “Already Over Promised”. This is something that the AOP guys are constantly fighting against. Gregor et al are NOT saying: “Use AOP everywhere, it is a silver bullet”. That is far from the truth. We are still learning where it makes sense to use AOP, and where it makes sense NOT to use it, and keep to OOP. AOP complements OOP, and should be used together. Where you find cross cutting concerns that you can represent cleaner in AOP, go for it. Hell, if you just want to play with it and use it in dev, but not production, knock yourself out. I would bet that in time, people will be joining the train at different stages, just like we saw with OOP.

As Ron mentioned, right now AOPs “killer app” seems to be middleware (like OOPs was UI), but as we learn and improve, we will start to see cross cutting concerns all over the business design.

Let’s keep talking about these things, and see where it goes!

I read Ramnivas’ AspectJ in Action (Manning). I thought he did a really good job on it, so I wrote up a book review on TSS. I am hoping that there will be more and more “real world”/practical AOP books as time goes on (and people get to test it on real projects!).

I had a great time interviewing Gregor Kiczales, the guy who founded AOP/AspectJ at Xerox PARC. It must be such an interesting time for him, to see AOP growing more and more, seeing other frameworks out there (and probably seeing some of them making mistakes his work has already gone through!).

Check out the interview and comment on what you thought of his comments!