On Thu, 2004-02-12 at 18:31, Chad Woolley wrote: > Jason van Zyl wrote: > > Personally, I think AOP where aspects are definted with XML is not a > > very good idea. You completely lose the power of the compiler and you > > are left to find your mistakes at runtime. And XML is just cumbersome > > and there is no way you could even come close with XML, to the power of > > the syntax AspectJ provides. Wes Isberg had a pretty good summary of > > some of the potential pitfalls of using XML in conjunction with AOP, > > I'll see if I can dig it up. > > Sorry, I can't resist putting in my off-topic $.02. > > First, the claim that XML-defined aspects can only be caught at runtime > is incorrect. AspectWerkz, with XML definined aspects, can use the > post-compiler approach just like AspectJ and report all compilation > failures then.
Not all tools have this, but I'm sure they all will catch up eventually. > Also, I totally agree with your point that aspects can often be misused > when a plain-java approach would be much more understandable and > straightforward. > > AspectJ is definitely more mature and powerful. It does currently > support some features that AspectWerkz does not (but the AspectWerkz > developers are steadily working to address these shortcomings). > > AspectJ is also, IMHO, very hard to learn. I'm not ashamed to admit > that the the AspectJ custom definition syntax often makes my head hurt > when I try to understand it. Of course this is just a learning curve > issue, but there is a lot of complex stuff to learn. > > AspectWerkz, in contrast, is much easier to learn. The XML definition > syntax is much closer to something that can be read and understood by > your average human. The arguments against coding in XML are all valid, > but it's definitely much more understandable than the AspectJ syntax. I guess that's a matter of opinion. I don't you have to be "smart" to understand the AspectJ as I know of many places where AspectJ is in production and used by normal Joe programmers. It certainly is a personal preference but the AspectJ team not focused on making AspectJ powerful but a great effort was made to try and make it comprehensible. Maybe this effort hasn't been entirely successful but I think in years to come people will see AspectJ might be a little ahead of its time. I think tools like AspectWerkz are great because it does help the adoption of AOP which I think is great, but just as OO took a great number of years to be adopted and there too were present intermediary tools and practices that allowed developers to do things in plain C, for example, I believe that things akin to AspectWerkz are analagous and as people become more comfortable with AOP they will turn to the languages and tools which embody AOP semantics natively and for Java at least that's AspectJ. > Also, in my experience, I think it is best to make your aspects as > "bare-bones" as possible. In other words, refactor out all the logic > that is not directly tied to the aspect into plain-java helper utility > classes. These can then be directly unit tested without worrying about > the complication of the aspect framework. I think this is a good > general approach to make your aspects more understandable and manageable. Not thing stopping you from doing this in AspectJ. Lots of folks use the aspects as glue so to speak. It's a common practice amongst AspectJ'ers. > Anyway, enough off-topic opinionated spew. But it's interesting, you have many good points and you speak from actually trying both tools so opinionated spew borne from experience is just fine with me :-) > Thanks, > Chad > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
