Re: RE: [aspectj-users] Philosophical Questions

[<a@xxxxxxxxxxxxxxx>]

Hello,

I fully agree here with you, Adrian.

kind regards 
   Arno

***********************************************
Arno Schmidmeier
phone +49/9151/90 50 30
Yes, I have realized projects with AspectJ
Yes, I do provide consulting services for AspectJ
************************************************
 


Adrian Colyer <adrian_colyer@xxxxxxxxxx> schrieb am 07.07.2003,
22:42:48:
> I wanted to jump in on this one too as its a topic that's been on my mind 
> these last few days. Here's how I see it...
> 
> When anyone first comes to AOP, the examples they see and the kind of 
> concerns that they deal with tend to be very "orthogonal" to the core 
> application they're working on (or "non-functional" if you like that 
> term). I'm talking about the classic things like tracing and logging and 
> error handling etc.. In the AspectJ tutorial we sometimes call them 
> "auxiliary" aspects. With those kinds of aspects in mind, then a "pure" 
> Java plus XML approach has a certain appeal - the aspects are not critical 
> to the core application, and "configuring" them via XML does not severely 
> impact your understanding of the program. In the J2EE / middleware 
> community which is very used to filters, interceptors, deployment 
> descriptors etc this will feel like a very natural thing to do.
> 
> The problem comes when you get beyond the 
> "oo-application-with-a-few-auxiliary-aspects-bolted-on-the-side" phase. 
> When you start to do aspect-oriented programming with core aspects as a 
> natural part of your application design, then all of a sudden the 
> framework + XML approach looks a whole lot less attractive. You really do 
> want a solution that works as part of the programming language, with your 
> development tools, expressing your intent as clearly as possible in the 
> source code. AspectJ lets you do that, and allows you to think of aspects 
> as first class entities in the language - this is so powerful. I don't 
> want to have to parse side XML files and perform a "weave" in my head in 
> order to figure out what my program means. Personally, I'll even use an 
> inner aspect inside a single class to handle a policy that cuts across the 
> methods of that class (acquiring and releasing connections in a db access 
> class for example) where it makes the intent clearer. You just wouldn't do 
> that with run-time interceptors and XML configuration.
> 
> So, I think that these frameworks have an appeal for folks looking at 
> auxiliary aspects. If that's all you want, then some of the frameworks are 
> very good examples of doing that. I also believe AspectJ is very good at 
> handling these kinds of concerns btw.. But if you want an approach that 
> takes you into aspect-oriented programming, that grows with you as your 
> confidence and understanding grows, and that gives you a uniform way of 
> handling aspects from development time aspects right through to core 
> function, then you need AspectJ. And once you've gone beyond auxiliary 
> aspects, and tasted what it's like to really explore aop, you'll never 
> look back :)
> 
> -- Adrian
> Adrian_Colyer@xxxxxxxxxx
> 
> 
> 
> 
> "Gregor Kiczales" 
> Sent by: aspectj-users-admin@xxxxxxxxxxx
> 07/07/2003 16:59
> Please respond to aspectj-users
>  
>         To:     
>         cc: 
>         Subject:        RE: [aspectj-users] Philosophical Questions
> 
> 
> I'm really glad you sent this message.  This reply is about a general 
> point, I'll tackle the specific points later today.
>  
> The flurry of alternative AOP frameworks is clearly a good thing. It shows 
> that AOP has moved from the invention phase to the first innovation phase. 
> More people are looking at the technology, in a solution oriented 
> approach, to see what it can do for them.This will be an exciting time.
>  
> But while I think lots of innovation is great, I worry that these systems 
> may cause people who are just starting to learn about AOP to reach some 
> false conclusions.  Specifically:
>  
>  - because these systems have no IDE support, they run the risk of stoking 
> the false argument that AO programs are hard to understand or debug. With 
> AspectJ, a simple ajdt demo is enough to show that these problems are 
> solved.
>  
>  - because these systems are dynamically typed, they run the risk of 
> convincing people that AOP is inefficient and also that debugging will be 
> more difficult with AOP.
>  
>  - because these systems don't necessarily have orthogonal join point 
> models, they may seem simpler, but run the risk of making larger AOP 
> programs more complex to write and/or understand.
>  
>  - because most of these systems are a subset of AOP, they run the risk of 
> causing people outside the community to complain that "the AOP people are 
> talking a lot about a very little". For example, many people look at these 
> systems and conclude that AOP is just interception -- they miss the whole 
> point about how pointcuts allow building up crosscutting structure.
>  
>  - because of the claims people make about these systems, they run the 
> risk of causing people to believe that no one is doing any commercial AOP 
> yet, and that AspectJ doesn't work. Many AOP developers would be better 
> served, IMHO, to use AspectJ with its much higher degree of engineering, 
> documentation and support.
>  
> Don't get me wrong, I strongly believe this round of innovation should 
> continue, it is a great thing. I am personally enjoying discussions with 
> some of the authors of these new systems as to elements of their design.
>  
> But I wish the voice of AspectJ experience was more represented in this 
> round of debate about using AOP in practice.  For example this idea that 
> AspectJ is too powerful needs some debunking. Its trivial to subset 
> AspectJ and still end up with an orthogonal, type-safe, efficient, system 
> that has 5 years of user experience with it. If size is the issue, that is 
> probably a better way to go.
>  
> So...
>  
> I'd really like to encourage AspectJ users who have running code and 
> experience to speak up more on the many blogs that are hosting most of 
> this round of AOP discussion. Please speak up! (Its sort of frustrating 
> that all this happens in individual blogs rather than discuss@xxxxxxxx, 
> but that's a whole other issue!)
> -----Original Message-----
> From: aspectj-users-admin@xxxxxxxxxxx 
> [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Merrick Schincariol
> Sent: Saturday, July 05, 2003 8:03 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: [aspectj-users] Philosophical Questions
> 
> Having just got back from TheServerSide Symposium in Boston, I can report 
> that AOP was definitely the talk of the conference. What was surprising to 
> me, however, was the lack of focus on AspectJ. Most comments were of the 
> form "it's too powerful for most developers" or that the special compiler 
> makes it difficult to sell in most organizations. Instead, most of the 
> talks focused on newer "pure Java" AOP frameworks.
> I personally find AspectJ to be a well designed implementation of AOP 
> concepts. On my weblog (http://www.freeroller.net/page/mschinc), I've been 
> documenting my own exploration of the capabilities that AspectJ provides. 
> Looking closer at "pure Java" approaches like AspectWerkz (
> http://aspectwerkz.codehaus.org/) something has been bothering me, but I 
> haven't been able to put my finger on it. I'd like to put a couple of 
> questions out to the list and see where your thoughts are on the subject.
> 1) Can Aspects themselves be broken down into smaller sub-components? 
> Most of the Java AOP frameworks break out aspects into a number of 
> different pieces. For example, you implement your advice as one Java 
> class, your introductions as another and then define (usually using XML) 
> the pointcuts and the relationships between the components. So one Aspect 
> could actually require many files to implement and define. Does the 
> complexity of this approach interfere with the AOP philosophy? My fear is 
> that when the implementation requirements are complex, from a language 
> point of view, you start to lose track of the problem you are actually 
> trying to solve.
> As an aside, I think the AspectWerkz design for advice is broken. Because 
> each type of advice is a class (pre, post and around) and each advice 
> class extends a pre-existing class, you can't share any information 
> between different types of advice on the same pointcut.
> 2) Can pointcuts be modeled separately from advice? 
> This follows on the above point, but it's one that I find a little odd. 
> Most (all?) of the pure Java approaches define their pointcuts in one file 
> and their advice in another. Presumably this means that advice can be 
> reused across multiple different aspect definitions. From a philosophical 
> point of view, can advice be modeled truly independently from pointcuts? I 
> would think that certain types of advice, particularly when dealing with 
> cflow and other advanced join points, really require the pointcut 
> definition to be present in order to make sense.
> 3) What role, if any, should metadata play in AOP? 
> I know Gregor has commented on the use of metadata a couple of times, but 
> the JBoss group is charging ahead with their "AOP" product which 
> encourages developers to use class metadata to load library aspects. This 
> strikes me as wrong in many ways, but the message that is reaching the 
> development community is that interceptors and metadata are all you need 
> to do AOP. Is this just a function of what's easy to implement, or are 
> people really having trouble grasping the concepts?
> I'm looking forward to hearing your thoughts. 
> Cheers, 
> Merrick