Aspect Programming Module

[Daniel Dittmar]

From direct personal experience, could some AOP folks please
point out some compelling use cases so that the doubting
Thomases (and Wills, and Peters) can better understand and
accept the idea of AOP as being more than just a few fringe
cases?

Not from personal experience, but these have been mentioned:
- multithreading: create class A' like class A, but with specific methods
synchronized
- persistence
- transactions: pass a transaction context through a call hierarchy spanning
several objects and let the transaction fail if certain methods fail

It may very well be that these can be implemented in current Python, but
this only means that Python already has good support for AOP.

Daniel

 

[Alexandre Fayolle]

I would be very interested to hear some real-world and real useful
use cases for AOP as well.

(The logging one actually annoys me: the only time I've ever
wanted such logging was when debugging very complicated problems,
and since switching to TDD I have never encountered anything
that even remotely made me consider writing such logging wrappers
again.)

I agree that TDD helps a lot. However, the logging module can be useful
when
* debugging a legacy/3rd party application or library
* trying to understand the data flow of a 3rd party library

Another "common" use of logilab.aspect is the contract aspect which
enables to specify pre and post conditions for methods as well as class
invariants. Of course, you generally don't need contracts when using TDD,
but when working with a distributed team on complex projects, it can be
a great time saver when diagnosing weird crashes. Especially if some
partners have not yet been test infected.
It is easy to disable contract checking once the project is said to
be stable enough and goes into production, or to re-enable the checks on
one offensive module or class if something weird happens.

Of course, it is possible to do this without AOP, and the flexibility
and introspection abilities of Python make it very easy to achieve, on an
ad hoc basis. It's just that using an AOP framework can save some typing,
as well as facilitate non invasive changes to existing code.

 

[Adrien Di Mascio]

Le Fri, 16 Apr 2004 17:22:08 +0200, Daniel Dittmar a écrit :

Not from personal experience, but these have been mentioned:
- multithreading
- persistence
- transactions
It may very well be that these can be implemented in current Python,but
this only means that Python already has good support for AOP.

All the examples you mentioned can be implemented in Python.
Maybe we could also add "profiling", "security" ...

IMHO, what's great (in this context) with Python is that it's possible
to weave code (or adapt code) dynamically wherever you want quite
easily. And that's (*only*) a part of AOP. Doing this by using
metaclasses, PEAK aspects, Pythius aspects, Logilab aspects, etc. this
does not really matter.

I think, and I might be wrong since I'm still a bit new to AOP, that
there is nothing that you can do with AOP that you could not do with a
plain OO program. (And any OO program could also be written in a non
object-oriented way). But AOP is here to let you improve reusability by
giving some new ways to factorize code. Someone in this thread (I think
it is Hung Jung Lu) defined AOP as being a kind of Fourier Transform of
OOP, and I like this way of defining it.

Cheers,
Adrien.

 

[Peter Hansen]

I would be very interested to hear some real-world and real useful
use cases for AOP as well. So far, the logging example seems to
be put forth so often that I'm starting to suspect that's the
*only* "useful" thing people are doing with it.

From direct personal experience, could some AOP folks please
point out some compelling use cases so that the doubting
Thomases (and Wills, and Peters) can better understand and
accept the idea of AOP as being more than just a few fringe
cases?

Thanks for the replies so far, but what concerns me is that
almost no one seems to have actually used AOP in their code.

Okay, I realize this is not the best forum to find a bunch of
AOPers, probably, so I'd like to expand the request to include
pointers to clear descriptions of *others'* compelling uses
of AOP. Not just cool or theoretical ideas, but actual
cases of AOP having been used for things where non-AOP
would have been much more awkward or involved or something.

The logging example is okay, yes, but another problem I have
with it is that it's very development-oriented. It doesn't
do anything directly for the user in terms of helping implement
user functionality. Same goes for the contract aspect, which
while probably very helpful for doing dBc in some cases, appears
just to make a particular development style go easier.

I'm not sure I'm asking this in the right way, but does AOP
provide one with the ability to do anything useful in terms
of actual end-user functionality, and if so please point me
to a description of a real-world case where it did so.

I'm not actually anti-AOP, just completely on the fence about
the possible benefits. I like the Fourier Transform way of
viewing it, but it's possible to relate FTs back to the real
world in a pretty direct manner as they just allow an easy
way to work in the frequency domain. What, in the AOP world,
is the equivalent to "frequency"?

-Peter

 

[Shane Hathaway]

- persistence
- transactions: pass a transaction context through a call hierarchy spanning
several objects and let the transaction fail if certain methods fail

Interesting you should mention these, since ZODB provides transactional,
transparent object persistence.

It may very well be that these can be implemented in current Python, but
this only means that Python already has good support for AOP.

This discussion makes me wonder if Zope has been dabbling in AOP
concepts for years without knowing it. In addition to ZODB, Zope lets
you declare permissions for methods, wraps objects with proxies to give
them an environment, and inspects method signatures to make them
directly callable by URL. The AOP folks talk about very similar things.
Surely there is some common thread.

Shane

 

[Joe Mason]

The logging example is okay, yes, but another problem I have
with it is that it's very development-oriented. It doesn't
do anything directly for the user in terms of helping implement
user functionality. Same goes for the contract aspect, which

It does if generating usage reports is a user requirement. Call logging
in a telephony app, for instance.

Joe

 

[Peter Hansen]

It does if generating usage reports is a user requirement. Call logging
in a telephony app, for instance.

Sorry, but that doesn't fly. That's a clearly separate function
that should have a simple, single call somewhere in the application.

The AOP logging example is talking about a "cross-cutting concern"
(did I get that right?) where one wants to log *all method calls*
in an object. It's a developer tool, not something that you would
use for call logging.

And even if it were, I'm still looking for real-world examples, not
hypothetical ones.

-Peter

 

[Terry Reedy]

This discussion makes me wonder if Zope has been dabbling in AOP
concepts for years without knowing it.

I believe at least one person has posted about AOP in Zope. Quite aware of
what doing ;-)

tjr

 

[Joe Mason]

Sorry, but that doesn't fly. That's a clearly separate function
that should have a simple, single call somewhere in the application.

Not at all. You'll want to log when calls start and end, when features
are turned on and off, when specific services (voice mail, call
forwarding) are accessed. If your app is for a call center, you want to
log when people go on and off hold and when they enter specific service
queues. Two years down the road a major customer will want to buy your
system, except they have incredibly specific requirements for report
generation which requires you to add even more entry points...

The AOP logging example is talking about a "cross-cutting concern"
(did I get that right?) where one wants to log *all method calls*
in an object. It's a developer tool, not something that you would
use for call logging.

No, where one can dynamically decide which method calls to log. The
point of "cross-cutting" is that you have the voice mail modules, and
the call forwarding module, and the service queue module, and they *all*
have to do logging. The examples just add to all methods of an object
because it's an easy demonstration.

Joe

 

[Peter Hansen]

Not at all. You'll want to log when calls start and end, when features
are turned on and off, when specific services (voice mail, call
forwarding) are accessed. If your app is for a call center, you want to
log when people go on and off hold and when they enter specific service
queues.

Okay, even given that we're talking about something hypothetical
(I'm _quite_ interested in evidence that AOP for such things is
more than just someone's cool theory), why wouldn't I just do this
as a series of calls in the appropriate places? If I'm going to
specify which methods of which classes/objects are getting this
"logging" functionality, it seems to me that I can do that as
easily (i.e. one line of code) by just making it explicit in
the code that does the call.

And if I had to do this in such a variety of "arbitrary" places
that it would appear to be a maintenance issue or something, I
would turn to data-driven programming and just have the appropriate
logging calls inserted using wrappers around the methods of
interest as the application configures itself.

So where does AOP fit in? I realize I'm basically asking the
same question some others have, as in what good does AOP provide
if it's so easy to do this using traditional techniques. Or is
anyone arguing that what I'm actually doing is AOP even though
I don't call it that? (In which case AOP should be relegated to
being a simple Software Pattern I guess.)

I think one problem I have with the logging example, even
modified from the contrived "log calls to all methods" case,
is that I've done such things, without the slightest feeling that
what I was doing was complicated or awkward or needed "a better way".
So what does AOP buy for such things?

(But I'm _really_ much more interested in real-world examples,
since we can discuss the theory of AOP all you like and still
not convince me or anyone that it's worth any change in our
way of doing things. What's a *compelling* example?)

-Peter

 

[Hung Jung Lu]

This discussion makes me wonder if Zope has been dabbling in AOP
concepts for years without knowing it. In addition to ZODB, Zope lets
you declare permissions for methods, wraps objects with proxies to give
them an environment, and inspects method signatures to make them
directly callable by URL. The AOP folks talk about very similar things.
Surely there is some common thread.

You are right on there. Zope has plenty of places where it could
use AOP or is using AOP-like techniques. I remember the days when I
was using SiteAccess. SiteAcess is a perfect example of AOP. In that
sense, Apache's ModRewrite is another prefect example.

ZODB is transactional. But Zope < 3.0 is not enterprise-transactional
a la MTS or EJB/J2EE. I am not experienced in the details of
implementation of transactional architecture, but I would guess part
of the difficulty in converting an existing application into a
fully-transactional application is because you have to modify code all
over too many places. This is the type of problems that AOP addresses.

regards,

Hung Jung

 

[John Roth]

I would be very interested to hear some real-world and real useful
use cases for AOP as well. So far, the logging example seems to
be put forth so often that I'm starting to suspect that's the
*only* "useful" thing people are doing with it.

From direct personal experience, could some AOP folks please
point out some compelling use cases so that the doubting
Thomases (and Wills, and Peters) can better understand and
accept the idea of AOP as being more than just a few fringe
cases?

(The logging one actually annoys me: the only time I've ever
wanted such logging was when debugging very complicated problems,
and since switching to TDD I have never encountered anything
that even remotely made me consider writing such logging wrappers
again.)

-Peter

I suspect you're not going to get any really compelling ones.
The reason I say this is a lot of experience I had about 30
years ago, when I was supporting an installation with IBM
mainframes, using MFT and MVT (the predecessors to MVS.)
One of my favorite methods of installing patches and modifications
was to insert code in the call paths between modules, using
patches and link editor gyrations.

Why? Because I couldn't get the source code to change it,
and even if I could have done so, changing it would have
exposed me to horrendous integration problems with
upgrades (something I had to learn the hard way.)

When you're supporting a monolithic proprietary application,
sometimes you have to do what you have to do, but today
the entire idea simply smells of a high-tech way to do
ad-hoc patching where a really well designed application
would not need it (and I don't really care if the design is
up front or emergent.)

John Roth

 

[John J. Lee]

AOP is a design technique, not just a set of tools. If it's true that
you can just use simple mixins in Python to get the same effect as
ApectJ, then you can say, "AOP is implemented on Python with mixins, but
Java requires language extensions such as AspectJ." That doesn't mean
Python doesn't "need" AOP - nobody really "needs" it, they just find it
a useful way of approaching problems, and moving to Python doesn't make
it a less useful approach. In fact, if it's easier on Python, it's more
useful.

Joe is surely on the right trail here.

What I wonder, though, is: Is AOP just another set of design patterns
that often work nicely together, or do the ideas involved form a much
more unified whole than that description implies? And is there a
significant break in thinking involved in moving from standard OOP to
AOP?

I listened to a introductory talk on AOP by Arno Schmidmeier yesterday
at the ACCU conference (Good talk: interesting, and I understood it --
in stark contrast to the stuff I'd read previously about it -- despite
Arno's suffering with a bad case of Powerpoint disease ;-). I asked
him whether he knew of any usefully mature Python implementations.

Of course, the mostly-tacit assumption behind my question (driven no
doubt by the name's similarity to 'OOP') was that AOP is indeed (at
the least) a blob of concepts and design techniques that.are much less
useful apart than they are together. More than that, in fact: that
doing AOP requires a significant change in the way you think about
design. I wonder if that's true, or if it just appears that way to
the users of static languages? Perhaps AOP is better regarded as
merely a bunch of design patterns that only appear to Java/C++ people
to be a new "paradigm" (in a very loose sense of the word) because of
the implementation techniques that those languages happen to force on
you when you try to implement these patterns. I'm sure it's not that
simple, but maybe there's some truth in that suspicion.

Whatever the answer, I wish there were a reasonably 'standard' set of
AOP tools available for Python so I could find out by experiment.
Standard in the concepts rather than implementation techniques, that
is.


John

 

[John J. Lee]

When you're supporting a monolithic proprietary application,
sometimes you have to do what you have to do, but today
the entire idea simply smells of a high-tech way to do
ad-hoc patching where a really well designed application
would not need it (and I don't really care if the design is
up front or emergent.)

That's unfair.

Regardless of your view of its importance, AOP is clearly sufficiently
well-motivated purely in terms of separation of concerns. That it's
also useful as a hack to patch badly-designed software written in
inflexible languages doesn't change that in the least.


John

 

[John Roth]

That's unfair.

Regardless of your view of its importance, AOP is clearly sufficiently
well-motivated purely in terms of separation of concerns. That it's
also useful as a hack to patch badly-designed software written in
inflexible languages doesn't change that in the least.

Maybe I should say it a bit clearer then. It still looks like a
hack to me.

One of the reasons I say this is that I work a bit with XP.
A major factor in XP is refactoring, driven by a relentless
search and destroy on any form of duplication. People who
do this pretty much say that they don't usually get into problems
where you have to go in and hack entry points into someone
else's modules.

It's a solution looking for a problem. The only place I can see
it being useful is for things like traces, where you don't want to
recompile the program just to stick in some monitoring, and
for programs that you don't own so that you can't fix the
darn thing.

John Roth

 

[Daniel Dittmar]

AOP is not about patching existing programs/libraries. This is just the
way it is usually implemented in Java.

Other approaches used for languages like C++ use code generation. Code
generation isn't as nifty and doesn't work as well for Java as Java
hasn't got a #line directive to guide the debugger. But it's You Can See
What You Get.

AOP grew out of the observation that an evergrowing percentage of the
code of the average method is taken over by parts that are not related
to the main purpose of the method, but by logging, sychronization,
transaction handling and other stuff.

This kind of code is often of the boilerplace kind, which lends itself
easily to code generation. And it requires often some context
information, which must then be passed either through parameters or
through objects, adding to the line noise that distracts from the 'real
code' of the method.

And the 'we do this through refactoring' argument ends where you use
external libraries unless you want to fork them.

Daniel Dittmar

 

[Dave Kuhlman]

[snip]


I suspect you're not going to get any really compelling ones.

Isn't AOP antithetical to the Pythonic admonition to make
everything explicit?

"Explicit is better than implicit."
-- The Zen of Python (by Tim Peters)

You can stare at a section of AOP code as intently as you like,
and never discover the changes that are woven into it.

A little more zen:

"Mysterious is the worst of all."

Dave

[snip]

 

[Joe Mason]

Will Stuyvesant wrote:

What are good usage examples?

[snip]


I suspect you're not going to get any really compelling ones.

Isn't AOP antithetical to the Pythonic admonition to make
everything explicit?

"Explicit is better than implicit."
-- The Zen of Python (by Tim Peters)

You can stare at a section of AOP code as intently as you like,
and never discover the changes that are woven into it.

You know, it strikes me that PEP318's decorators could be a nice way to
weave an aspect into a method explicitly, with a tag on the method,
rather than implicitly, with a list of weaves somewhere else in the
program.

Joe

 

[Michael Hudson]

Thanks for the replies so far, but what concerns me is that
almost no one seems to have actually used AOP in their code.

What do you understand "AOP" to mean? One meaning of "AOP" seems to
be a collection of techniques and tools to make programming in the
Java environment a pleasanter experience. This meaning hardly applies
to programming in Python...

Cheers,
mwh

 

[Peter Hansen]

What do you understand "AOP" to mean? One meaning of "AOP" seems to
be a collection of techniques and tools to make programming in the
Java environment a pleasanter experience. This meaning hardly applies
to programming in Python...

I have no predefined meaning. I'm not about to run out and
spend a lot of time researching something for which I have
no reason (yet) to believe there is a practical use which would
solve any problems I have. I'm hoping that someone here can
point out such uses and help define the meaning for Python folks
such as me.

Yours is at least the second comment suggesting that AOP is a
somewhat Java-specific, or at least shows more obvious use in the
Java world (of heavy static typing) than in the Python world.

-Peter