AOP and pep 246

[Carl Banks]

On Nov 2, 12:10 am, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> "Rustom Mody" <rustompm... at gmail.com> writes:
> > On 11/1/07, Kay Schluehr <kay.schlu... at gmx.net> 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