Re: AOP languages mature enough to used in industry

Hi Dean,

Am 18.05.2007 um 14:23 schrieb Dean Wampler:
> Unless I'm mistaken, Spring supports the AspectJ pointcut language  
> for specifying where to apply advice/proxies as well as its  
> original syntax that is more like "apply an advice-like proxy to  
> this single class".

right. I was referring to the older versions of Spring AOP that  
didn't yet support AspectJ pointcuts, and also to similar interface  
mapping-based approaches like AspectS and COP in its various  
instantiations.

> My real point about the pointcut language (excuse the pun... ;) is  
> that a strong pointcut language is essential for AOP because we  
> need the ability the specify a complex collection of join points,  
> including various static and dynamic conditional constructs, in  
> order to have a truly modular system. That is, if AOP allows me to  
> modularize a concern, I need the ability to specify this in a very  
> succinct way in a single module. Apply advice is the easy part,  
> even in java, where there are plenty of good byte-code manipulation  
> libraries.

Pun excused. :-)

I also like to reason about aspects (and look-alikes) from a  
modularity-oriented point of view. After all, aspects are modules,  
aren't they?

But if they are, then what makes them so special that they are  
allowed to dishonour other modules' privacy by being invasive about  
their specification of interaction with other modules?

(Continued below.)

> Of course, this is the low-level stuff. We also need good  
> constructs for modular specification of concerns at higher levels  
> of abstraction.

If you are saying that pointcut languages, seen the way they are  
approached mostly today, are actually low-level stuff, then I'm with  
you. All this reasoning in terms of field access here, method call  
there, ... *is* low-level. Stateful aspects, tracematches,  
annotations, the full model Alpha supports... that's much more like it.

Reasoning about module interactions in terms of modules looks much  
more digestible to me than doing it in terms of module intestines, so  
to speak. Every single module knows about its intestines, and that's  
good; but it should also be enough. So if there is something in  
module X that another module should react to, then X should know how  
to say this. XPIs seem like a good idea in this regard.

Best,

Michael

-- 
Dr.-Ing. Michael Haupt                [email protected]
Software Architecture Group           Phone:  ++49 (0) 331-5509-542
Hasso Plattner Institute for          Fax:    ++49 (0) 331-5509-229
Software Systems Engineering          http://www.swa.hpi.uni-potsdam.de/
Prof.-Dr.-Helmert-Str. 2-3, D-14482 Potsdam, Germany

Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Potsdam
Amtsgericht Potsdam, HRB 12184
Geschäftsführung: Prof. Dr. Christoph Meinel



_______________________________________________
discuss mailing list    -    [email protected]

To unsubscribe and change options, go to:
http://aosd.net/mailman/listinfo/discuss_aosd.net

Check out the AOSD.net Wiki: http://aosd.net/wiki