Lambda the Ultimate

inactiveTopic Aspect-Oriented Programming with AspectJ™
started 3/12/2001; 5:00:53 AM - last post 3/12/2001; 8:57:22 AM
Ehud Lamm - Aspect-Oriented Programming with AspectJ™  blueArrow
3/12/2001; 5:00:53 AM (reads: 1081, responses: 2)
Aspect-Oriented Programming with AspectJ™
A very detailed exposition of aspect oriented programming in the context of Java, as implemented by AspectJ.

Aspects are an interesting concept, and give an interesting perspective on modulatrization. Most implementation ideas I saw seems far from elegant. AspectJ seems much better.

Of course, from our point of view aspects, as in AspectJ, are a language extension.

(other file formats are available)
Posted to Software-Eng by Ehud Lamm on 3/12/01; 5:01:32 AM

Chris Rathman - Re: Aspect-Oriented Programming with AspectJ™  blueArrow
3/12/2001; 7:59:08 AM (reads: 1127, responses: 0)
A while back I posted a response about AspectJ that I thought I'd repeat here:
AspectJ Sounds interesting but dangerous...

As I see it, they are trying to accomplish a couple of different things through a similar technique. The first is based on providing a debugging network where the tools basically use a bunch of Visitor classes to capture information about the calls, usage and performance information. Not a bad idea, but I don't consider that to be a programming paradigm so much as a debugging tool. Something that's best taken care of by your environment tools and profilers.

The second usage is along the same lines, but uses a Visitor type pattern to allow updates to similar code scattered throughout your object graph. In a roundabout fashion, this is an attempt to solve one of Bryce Jacob's complaint about classes being organized around data types rather than functions. The tools apparently allow you to view and modify similar functions that are scattered across different classes. The only problem I have with this is that it acts that same way code generators do - you're modifying code in possibly unexpected ways and not localizing the effects. It may be a hassle to manually visit and touch these functions, but at least you're not prone to getting unexpected side effects when your trying to solve an isolated problem.

The last usage has to do with generating Design Patterns in rapid fashion. This allows you to generate the necessary classes for the various patterns. Kind of like a code wizard for patterns where the tool generates a shell of all the classes and you fill in the necessary gaps. Could be useful in a limited context but I'm not one that really likes wizard tools that generate code as they always seem to do needless things and invariably write code in a different style than I do (a lot of this is hatred for Visual C++ so it's possible that my bias against wizards is showing through). In the end, you still need to understand all the code that is generated.

All and all, my initial reaction is fairly cool to AOP. But then I've not studied it in depth either so I could be completely wrong. :-)

Ehud Lamm - Re: Aspect-Oriented Programming with AspectJ™  blueArrow
3/12/2001; 8:57:22 AM (reads: 1135, responses: 0)
Interesting commnets. I'll have to think about them...

My first reaction to AOP was not overly enthusiastic either, and I haven't used any of this to do real work. I find the idea of aspects interesting, and I think it captures a real problem in SE. However, I am not sure I like the solution.

What realy bothered me when I first looked at AOP was the idea of seperate component and aspect languages. It seems things are more well integrated in AspectJ.

Have you read this paper? It is long and a bit tedious but I think it deals with some of your objections.