On Nov 2, 12:10 am, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > "Rustom Mody" <[EMAIL PROTECTED]> writes: > > On 11/1/07, Kay Schluehr <[EMAIL PROTECTED]> wrote: > > > AOP was a research that gone nowhere - at least not in its orginal > > > AspectJ form: declaring aspect code that targets business code... > > My own guess is that AOP via higher order functions and metaclasses > > will be more successful than via aspectj and code-generation. > > I've never been able to figure out what AOP was supposed to mean.
AOP is a programming paradigm in the same way indie is a genre of film. It essentially means, "anything that is congnitively simple but not simply implemented in your language of choice". Hence the oft-heard purpose of AOP to address "cross-cutting concerns". If you don't have a convenient representation in your language of some cognitively simple thing ("aspect"), then you have break up the implementation of it in unpleasant ways. Your concern must cross many files. Java, for instance, supports only one simple congitive concept--the object--and not as well as it could. Pretty much any concern that isn't nicely encapsulated in an object would be a "cross-cutting concern" and hence "aspect" that AOP would address. For example, suppose after careful consideration you were to decide to centralize XML serialization of many different object types in its own package. Java's strict object-orientated paradigm is your enemy here, especially without the benefit of multiple inheritance(**). AOP to the rescue. With AOP, you can say, "No problem. I'll just use AspectJ to weave that XML serialization into the classes, and then I can keep the serialization in a central location where it belongs." Needless to say, Python there is broad support for many aspects of design, so that many "cross-cutting concerns" in Java would be ordinary programming in Python. Python culd handle the above problem without any code weaving, and some solutions would be natural enough that it wouldn't even occur to someone that they were using a different paradigm. That's why I prefer the term Aspect-Aware Programming, or Aspect-Aware Design. The idea is that different aspects aren't necessarily organized the same way. Many things fit neatly into an OO organization; other things do not. With AAP you organize some aspects in one way, other aspects in other ways, and it works out. A dynamic language like Python has good support for AAP already, but a rigid, static, precriptive language like Java needs to resort to hacks like AspectJ. Footnote: (**) One sometimes-effective way to tack behavior onto an existing set of classes is to derive a new set that multiply inherits from the existing set and a bunch of mixins with your own behavior. The approach has drawbacks, but sometimes it works ok, and would be quite useful in Java. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list