Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Aspect Programming Module

Reply
Thread Tools

Aspect Programming Module

 
 
Daniel Dittmar
Guest
Posts: n/a
 
      04-16-2004
Peter Hansen wrote:
> 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


 
Reply With Quote
 
 
 
 
Alexandre Fayolle
Guest
Posts: n/a
 
      04-16-2004
Le 16-04-2004, Peter Hansen <(E-Mail Removed)> a écrit*:
> Will Stuyvesant wrote:
>
>> What are good usage examples?

>
> 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.

--
Alexandre Fayolle LOGILAB, Paris (France)
http://www.logilab.com http://www.logilab.fr http://www.logilab.org
 
Reply With Quote
 
 
 
 
Adrien Di Mascio
Guest
Posts: n/a
 
      04-16-2004
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.

 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      04-16-2004
Peter Hansen wrote:
> 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
 
Reply With Quote
 
Shane Hathaway
Guest
Posts: n/a
 
      04-17-2004
On 04/16/04 11:22, Daniel Dittmar wrote:
> - 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

 
Reply With Quote
 
Joe Mason
Guest
Posts: n/a
 
      04-17-2004
In article <(E-Mail Removed)>, Peter Hansen wrote:
> 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
 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      04-17-2004
Joe Mason wrote:
> In article <(E-Mail Removed)>, Peter Hansen wrote:
>
>>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.


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
 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      04-17-2004

"Shane Hathaway" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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




 
Reply With Quote
 
Joe Mason
Guest
Posts: n/a
 
      04-17-2004
In article <(E-Mail Removed)>, Peter Hansen wrote:
> Joe Mason wrote:
>> In article <(E-Mail Removed)>, Peter Hansen wrote:
>>
>>>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.

>
> 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
 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      04-17-2004
Joe Mason wrote:

> In article <(E-Mail Removed)>, Peter Hansen wrote:
>>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.


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Aspect Oriented Programming ar3492@student.open.ac.uk Java 1 01-17-2008 02:54 PM
Aspect oriented programming. John Gagon C++ 4 05-16-2006 03:42 PM
general question to aspect-oriented-programming Julia Donawald Java 0 12-30-2004 11:05 PM
Aspect Oriented Programming techniques christopher diggins C++ 15 02-11-2004 08:41 PM
Ann: Aspect-Oriented Programming with C++ and AspectC++ Daniel Lohmann C++ 0 02-10-2004 05:48 PM



Advertisments