Aspect Programming Module

[Anton Vredegoor]

Hmmm. When I started this reply, I was going to emphasize that 'separating
concerns' is much less efficient than more directly writing

The problem is *which* concerns are to be separated.

def fgen():
#generate fibonacci sequence
a,b = 0,1
while 1:
a,b = b,a+b
yield a

def fib(n, L = [], g = fgen()):
#interface with fibonacci generator
if n < 0 :
return 1
while len(L) <= n:
L.append(g.next())
return L[n]

def test():
print fib(500)

if __name__=='__main__':
test()

Anton

 

[Terry Reedy]

The problem is *which* concerns are to be separated.

def fgen():
#generate fibonacci sequence
a,b = 0,1

# add yield a to define fib(0) as 0, as some do

while 1:
a,b = b,a+b
yield a

def fib(n, L = [], g = fgen()):
#interface with fibonacci generator
if n < 0 :
return 1
while len(L) <= n:
L.append(g.next())
return L[n]

Nice. Generalizing the wrapper gives

def listify(gen):
it = gen()
cache = []
def func(n):
while len(cache) <= n:
cache.append(it.next())
return cache[n]
return func

fib = listify(fgen)

Alternative is
def listify(iterable):
it = iter(iterable)
....
#which then requires
fib = listify(fgen())

I agree that separating and wrapping the function as generator or iterator
is even better that as regular function. I have use for this. Thanks.

Terry J. Reedy

 

[Jacek Generowicz]

<chuckle> There's a large contingent of folks in the world,
not trained as computer scientists, who would question the
claim that anything involving Fibonnaci sequences makes
a good "real world" example. ;-)

It's not meant to be a real world example; it's meant to be a quick
demonstration of what separation of concerns is (to someone who seems
to be being deliberately obtuse about it, it seems (not you, Peter)).

 

[Jacek Generowicz]

The funny thing about this example is that its success critically depends
on fib *not* being 'optimized' by having the recursive calls being either
compiled as or replaced by (as with Hettinger's recent proposal) efficient
local calls.

Please remember that the _point_ of the example is to show what
separation of concerns is, in the context of the claim that C moving
IO from language to library constitutes separation of concerns.

Picking nits in the implementation details is completely missing the point.

 

[Richie Hindle]

[Will]

It's all abstract chitchat [...] Forget about *real* real-world
examples, these people just want to get papers published. [...]
AOP is nothing more than what I expect from a decent programmer:
a good, or at least reasonable, design of software in the first
place.

This whole AOP discussion reminds me of this from the ever-relevant
Hitch-Hiker's Guide:

Slowly, however, the implications of the idea began to be understood. To
begin with it had been too stark, too crazy, too much what the man in the
street would have said, 'Oh yes, I could have told you that,' about. Then
some phrases like 'Interactive Subjectivity Frameworks' were invented, and
everybody was able to relax and get on with it.

I'm happy to be a man in the street on this one. Let the Java crowd invent
shiny new TLAs.

 

[Michael Walter]

thank you for this explanation... it's the best explanation i've heard
yet and now i have a grasp and can visualize what AOP is.

bryan

That sounds like a description of (CL/Scheme-style) macros

Cheers,
Michael

 

[Dave Kuhlman]

That sounds like a description of (CL/Scheme-style) macros

So, arbitrarily complex transformations on the source code with
the intent of hiding the intension of the source code are good,
right?

I wish I could say something to satirize this. But, the post
about XML/XSLT seems satirical enough.

Dave

 

[Eric Eide]

Will> Forget about *real* real-world examples, these people just want
Will> to get papers published.

Perhaps that explains IBM's excitement about aspect-oriented technologies, as
reported here:

<http://news.com.com/2100-1008-5178164.html>
<http://www.theserverside.com/articles/article.tss?l=AOSD2004-2>
<http://www.sys-con.com/story/?storyid=44214>

Will> Usability is considered of minor impportance.

Perhaps that explains why AspectJ 1.1 received a Jolt Productivity Award in the
"Languages and Development Environments" category, as reported here:

<http://sdmagazine.com/jolts/>

Will> I have come to the conclusion that AOP is nothing more than what
Will> I expect from a decent programmer: a good, or at least
Will> reasonable, design of software in the first place.

I would say that the *goal* of AOP is "nothing more" that what you would expect
from a good programmer: good implementation of good software designs. AOP is a
an approach that augments existing approaches, such as OOP, for obtaining that
goal.

Eric.

PS --- ObPython: I think it would be great to see more Python involvement in
the AOP/AOSD community!

 

[Terry Reedy]

To be more precise, the example depends on dynamic lookup not being
disabled *before* the wrapping. But I believe *after* would be ok.

Please remember that the _point_ of the example is to show what
separation of concerns is, in the context of the claim that C moving
IO from language to library constitutes separation of concerns.

That may have been *your* point in writing it, but given that I never
seriously considered the claim you refuted as being worth much attention, I
had a different point in reading your example ;-)

Picking nits in the implementation details is completely missing the

point.

Given that I expect to someday make use of Hettinger's recipe, it is not
nitpicking for me to notice the interaction between the two patterns and
how to mix them and get the intended result.

Terry J. Reedy

 

[Daniel Dittmar]

So, arbitrarily complex transformations on the source code with
the intent of hiding the intension of the source code are good,
right?

What do you think a C compiler is doing? "But it's still my code, the
compiler simply allows to run it on a another processor." AOP tries to
provide transformations so that it is still your code, but that it can
run in a multitude of contextes (example: single user, servlet engine,
transaction monitor).

There are other approaches like code generation. But chances are that
that multiple code generators cannot be combined easily, as each
precompiler will reject the syntax extensions of the others as syntax
errors.

Daniel

 

[Bryan]

Michael Walter wrote:




So, arbitrarily complex transformations on the source code with
the intent of hiding the intension of the source code are good,
right?

I wish I could say something to satirize this. But, the post
about XML/XSLT seems satirical enough.

Dave

for me, i thought it was some really new cool concept. i was swimming in buzz words like "separation of concerns" and
having trouble getting to the meat of what it really was. but then it turns out that all it is nothing more than
XML/XSLT, oops, i mean "Java/AOPT". of course when you think this way, you easily see why logging is always chosen as
the perfect example. i just cannot see this as part of a general purpose programming technique. in some funcky way,
it's like factoring sideways instead of factoring up... does that make any sense? how can an "AOPT" keep up with my
functions, methods, callbacks, messages, queues, events, xmlrpc calls, c extensions, etc. how can an AOPT writer write
generic code unless the data supports some strict interface so it can be transformed. then if you must have a strict
interface, why not use some other OOP technique. dang, this is insane once you really think about it. if someone can
help me see something that i'm missing i really welcome the feedback.

bryan

 

[Tor Iver Wilhelmsen]

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.

A couple of other examples:

- Implementing Singleton as an aspect which states that calling
set*(self, value) methods on a set of classes should raise an
AttributeError - or just do nothing
- Measure execution time of a method by wrapping an aspect-"advice"
around it

An AOP mechanism for Python i googled up:

<URL: http://cvs.sourceforge.net/viewcvs.py/
pythius/pythius/pythius/aop.py?rev=1.36&
content-type=text/vnd.viewcvs-markup >

 

[Peter Hansen]

A couple of other examples:

- Implementing Singleton as an aspect which states that calling
set*(self, value) methods on a set of classes should raise an
AttributeError - or just do nothing
- Measure execution time of a method by wrapping an aspect-"advice"
around it

Hmm.... maybe I need to clarify what I mean by "real-world".

To mean, the term means something like "drawn from actual, working
code in real projects implemented to achieve useful, practical
results", as opposed to what, so far, pretty much everyone who
proposes examples seems to think, which is more like "potentially
interesting theoretical ideas which sound kinda cool"...

Has anyone used AOP in a real project, which wasn't a project just
to demonstrate AOP? For anything other than the logging example?
If so, what was the specific value provided by AOP, and can you
post a snippet or two of code which demonstrates the cleaner structure
provided by the clear separation of concerns which you believe comes
from AOP practices? And thank you.

(And I'll reject at this point examples which are no different than
how any number of us use Python to wrap existing methods in
useful ways, such as the synchronization scheme presented earlier
in this thread. Why? Because if that's the best you can do, then
I don't think AOP deserves to be recognized in the Python world as
anything other than a fancy buzzword for something which we should
all be doing already as we ensure our code is decoupled and has little
duplication. That probably means your example will come from the
Java world, or elsewhere, but I wouldn't reject it out of hand just
because it's in Python.)

-Peter

 

[Tor Iver Wilhelmsen]

- Implementing Singleton as an aspect which states that calling

Argh, I meant Immutable, og course.

 

[Anton Vredegoor]

I agree that separating and wrapping the function as generator or iterator
is even better that as regular function. I have use for this. Thanks.

Your idea of making the wrapping independent of the generator is very
interesting. I have been playing with it and produced a vector class.

It's not meant for serious production code (who knows however what
such wrapped generators might be used for but it might be
interesting to those who want to invade the dictionary noosphere.

It's at:

http://home.hccnet.nl/a.vredegoor/vector/

Anton

 

[Will Stuyvesant]

[Eric Eide, from the academics]

Will> Forget about *real* real-world examples, these people just want
Will> to get papers published.

Perhaps that explains IBM's excitement about aspect-oriented technologies, as
reported here:

<http://news.com.com/2100-1008-5178164.html>
<http://www.theserverside.com/articles/article.tss?l=AOSD2004-2>
<http://www.sys-con.com/story/?storyid=44214>

Thank you for the links.

Will> Usability is considered of minor impportance.

Perhaps that explains why AspectJ 1.1 received a Jolt Productivity Award in
the "Languages and Development Environments" category, as reported here:

<http://sdmagazine.com/jolts/>

AspectJ is for Java...

Will> I have come to the conclusion that AOP is nothing more than what
Will> I expect from a decent programmer: a good, or at least
Will> reasonable, design of software in the first place.

I would say that the *goal* of AOP is "nothing more" that what you would
expect from a good programmer: good implementation of good software
designs. AOP is a an approach that augments existing approaches, such as
OOP, for obtaining that goal.

One of my original points was that Java needs "AOP" to solve problems
imposed by the static typing system. The links you provide are
Java-centric. A better designed programming language, like the
dynamicall typed language Python, does not need "AOP". It is up to
the software designer to make good designs, orthogonal where needed,
with separation of concerns, etc.

 

[Eric Eide]

Will> One of my original points was that Java needs "AOP" to solve
Will> problems imposed by the static typing system. The links you
Will> provide are Java-centric. A better designed programming
Will> language, like the dynamicall typed language Python, does not
Will> need "AOP". It is up to the software designer to make good
Will> designs, orthogonal where needed, with separation of concerns,
Will> etc.

I think that we disagree about the nature of AOP. Perhaps I should review your
previous posts to see why you think AOP is primarily about working around
"problems imposed by the static typing system." I don't agree with this claim.

To me --- and I think the AOSD literature and community supports this view ---
AOP is about structure and problem decomposition, just like OOP is about these
things. AOP is not primarily about working around technical problems in a base
language, Java or otherwise.

Not all AOP research is done in Java, or even in statically typed languages.
See, for instance, a recent paper about implementing an AOP system in Scheme:
http://www.cs.brown.edu/~sk/Publications/Papers/Published/tk-ptcts-adv-ho-lang/

You claim that Python doesn't need AOP because it is "a better designed
programming language." If you believe that, what about OOP?

Do you think that Python needs OOP? If so, why? I don't mean to start a holy
war, but consider that Scheme does quite well without inherent OOP. Should we
consider Python's support for OOP evidence that Python is defective in some way
with respect to Scheme, and that Scheme is therefore "a better designed
programming language" because it "needs" neither AOP nor OOP?

Thank you for explaining your point of view!

Eric.

 

[Eric Eide]

Peter> Hmm.... maybe I need to clarify what I mean by "real-world".
Peter>
Peter> To mean, the term means something like "drawn from actual,
Peter> working code in real projects implemented to achieve useful,
Peter> practical results", as opposed to what, so far, pretty much
Peter> everyone who proposes examples seems to think, which is more
Peter> like "potentially interesting theoretical ideas which sound
Peter> kinda cool"...
Peter>
Peter> Has anyone used AOP in a real project, which wasn't a project
Peter> just to demonstrate AOP? For anything other than the logging
Peter> example? If so, what was the specific value provided by AOP,
Peter> and can you post a snippet or two of code which demonstrates the
Peter> cleaner structure provided by the clear separation of concerns
Peter> which you believe comes from AOP practices? And thank you.

Perhaps you would be interested in IBM's recent paper, which was presented at
the AOSD 2004 conference:

Adrian Colyer and Andrew Clement. ``Large-Scale AOSD for Middleware.''
In Proceedings of the 3rd International Conference on Aspect-Oriented
Software Development, Lancaster, UK, March 2004, pages 56--65.
<http://doi.acm.org/10.1145/976270.976279>

ABSTRACT

For a variety of reasons, today's middleware systems are highly
complex. This complexity surfaces internally in the middleware
construction, and externally in the programming models supported and
features offered. We believed that aspect-orientation could help with
these problems, and undertook a case study based on members of an IBM
middleware product-line. We also wanted to know whether
aspect-oriented techniques could scale to commercial project sizes with
tens of thousands of classes, many millions of lines of code, hundreds
of developers, and sophisticated build systems. This paper describes
the motivation for our research, the challenges involved, and key
lessons that we learnt in refactoring both homogeneous and
heterogeneous crosscutting concerns in the middleware.

Now you might discount this as primarily being "a project just to demonstrate
AOP," but I think that that would be unfair. Certainly a goal of the case
study was to evaluate AOP, but it was definitely in the context of a specific
and "real-world" task. I hope you enjoy it!

For more pointers to real-world uses of AOP/AOSD, I'd suggest asking around in
the AOSD discussion mailing lists hosted at <http://aosd.net/>. I don't have a
catalog of commercial uses handy, but the folks on the list are friendly .

Eric.

 

[Peter Hansen]

Should we
consider Python's support for OOP evidence that Python is defective in some way
with respect to Scheme, and that Scheme is therefore "a better designed
programming language" because it "needs" neither AOP nor OOP?

But isn't that exactly true? <0.1 wink only>

-Peter

 

[Peter Hansen]

Perhaps you would be interested in IBM's recent paper, which was presented at
the AOSD 2004 conference:

Adrian Colyer and Andrew Clement. ``Large-Scale AOSD for Middleware.''
In Proceedings of the 3rd International Conference on Aspect-Oriented
Software Development, Lancaster, UK, March 2004, pages 56--65.
<http://doi.acm.org/10.1145/976270.976279>

Thanks, but """Full-Text is a controlled feature.
To access this feature:
* Please login with your ACM Web Account.
* Please review the requirements below.
"""

And it appears memberships must be purchased.

Now you might discount this as primarily being "a project just to demonstrate
AOP," but I think that that would be unfair.

Perhaps, but I'll reserve judgment until I see significant signs of it
being used outside of such projects nevertheless.

-Peter