AOP and pep 246
Rustom Mody
google-ly) reaches peak.
But peak seems to be discontinued.
Whereas pep-246 on adaptors seems to be rejected in favor of something else.
What??
Can someone please throw some light on whats the current state of the art?
Kay Schluehr
AOP was a research that gone nowhere - at least not in its orginal
AspectJ form: declaring aspect code that targets business code,
weaving the aspect code into the business app using a code generator.
There was much excitement about it around 2001 that faded away since
then. What's left from the glory are certain classes of higher order
functions - you might call them "decorators".
When you want to restore the AOP research program in its full
flexibility for your own purposes without using a code generator you
can keep a higher order decorator and customize functions following
the rationale of this recipe:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/528929
I do think most people prefer a more direct style of composition that
is better localized. I actually never used this recipe for any
production code.
Michele Simionato
Rustom Mody
> AOP was a research that gone nowhere - at least not in its orginal AspectJ form:
> declaring aspect code that targets business code, weaving the aspect code into the
> business app using a code generator. There was much excitement about it around 2001
> that faded away
Maybe so but five years maybe too short to decide this.
Consider that the core ideas of LISP -- interpretation,
garbage-collection, s-exps-as-universal data-structure (now XML) have
taken 50 years to get into the mainstream.
Of course its also true that the number of dead-end ideas exceeds the successes.
My own guess is that AOP via higher order functions and metaclasses
will be more successful than via aspectj and code-generation.
In short python will do better than java. And so.. thanks for the link
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/528929
On 11/1/07, Michele Simionato <michele....@gmail.com> wrote:
> See http://www.python.org/dev/peps/pep-3119
Thanks Michele. But there are a couple of questions on this:
a. Does one have to use python 3000 for this?
b. Are there more example-oriented writings on this (such as the
papers you and mertz wrote on this stuff within the older paradigm
c. Where does peak stand today?
Paul Rubin
> On 11/1/07, Kay Schluehr <kay.sc...@gmx.net> wrote:
> > AOP was a research that gone nowhere - at least not in its orginal
> 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. I
once saw an explanation in terms of Haskell monads that made more
sense than the Java explanations, but I still didn't make sense of it.
Maybe something like it could be done with Python metaclasses. Here's
a url that I quickly googled just now, though I don't think it's the
paper I remember reading some time ago:
Michele Simionato
> > Seehttp://www.python.org/dev/peps/pep-3119
>
> Thanks Michele. But there are a couple of questions on this:
>
> a. Does one have to use python 3000 for this?
I expect ABC's to be backported to Python 2.6, but it is probably
possible to backport them down up to Python 2.2.
> b. Are there more example-oriented writings on this (such as the
> papers you and mertz wrote on this stuff within the older paradigm
Not that I know of (except posts in python-dev).
> c. Where does peak stand today?
My understanding is that P.J. Eby has no time to follow PEAK
fully; his idea is to extract the most useful ideas from PEAK
(you may know that eggs and WSGI originated from PEAK) and to
make them available to the community as separated packages. IOW,
PEAK as a monolithic framework had no success, but pearls of PEAK
are having an enormous impact. This is yet another example of
"simple is better than complex" and the ultimate reason why AOP
a la Java was a dead idea from the beginning. Too invasive.
If you want to have success, you must start from simple
things.
Michele Simionato
Kay Schluehr
>
> > AOP was a research that gone nowhere - at least not in its orginal AspectJ form:
> > declaring aspect code that targets business code, weaving the aspect code into the
> > business app using a code generator. There was much excitement about it around 2001
> > that faded away
>
> Maybe so but five years maybe too short to decide this.
>
> Consider that the core ideas of LISP -- interpretation,
> garbage-collection, s-exps-as-universal data-structure (now XML) have
> taken 50 years to get into the mainstream.
>
> Of course its also true that the number of dead-end ideas exceeds the successes.
> My own guess is that AOP via higher order functions and metaclasses
> will be more successful than via aspectj and code-generation.
>
> In short python will do better than java. And so.. thanks for the link
Yes. The methodological apparatus and terminology of AOP was invented
for Java or another language that fits cleanly into the OO paradigm of
"classes first". Aspects were a complementary modularization mechanism
for crosscutting features that did not fit into the "classes first"
ideology but were nevertheless modelled after classes. When you look
at AspectJ code you will find all kinds of lexical dependencies since
aspect code had to determine its join points using code pattern. Very
brittle! Now compare this to decorators which do not have to declare
where they are applied. You just decorate an appropriate function /
method. Since higher order functions give you all this for free there
isn't a real need to continue the semiotic legacy of AOP.
Note that I actually do believe that code generation will increase in
importance but not as an ordinary software engineering technique that
provides better modularization of application code. I consider this as
a failed idea.
Paddy
> On 1 Nov., 16:18, "Rustom Mody" <rustompm...@gmail.com> wrote:
>
> > I am interested in AOP in python. From here one naturally (or
> > google-ly) reaches peak.
> > But peak seems to be discontinued.
> > Whereas pep-246 on adaptors seems to be rejected in favor of something else.
>
> > What??
>
> > Can someone please throw some light on whats the current state of the art?
>
> AOP was a research that gone nowhere - at least not in its orginal
> AspectJ form:
If you Verify integrated circuits then you might know of the Specman e
language (http://en.wikipedia.org/wiki/Specman), That pre-dates
AspectJ and is very much
alive. Its AOP feature-set is different to that of AspectJ.
Our Verification engineers find the AOP paradigm to be very
productive. It
allows them to write a testbench in e and use AOP to extend it to
create
different testcases.
Just found a version of the LRM online (search for 'extend'):
http://www.ieee1647.org/downloads/prelim_e_lrm.pdf
- Paddy.
Carl Banks
> "Rustom Mody" <rustompm...@gmail.com> writes:
> > On 11/1/07, Kay Schluehr <kay.schlu...@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
Yu-Xi Lim
>
> AOP is a programming paradigm in the same way indie is a genre of
> film.
I like your explanation! Heck, if it were more directly Python-related,
I'd nominate this line for QOTW.
Rustom Mody
of being simplistic:
Kay: AOP == AspectJ or thereabouts. A failure in itself and
uninteresting to pythonistas
Michele: AOP not very interesting though does good work himself in
decorators, metaclasses and other such AOPish stuff
Carl: Aspect == something (anything?) cognitively coherent. AOP
(rather AAP) means: When a language feature supports an aspect use it,
when not wriggle round it. Python requires less wriggling than java.
A powerful conceptual viewpoint but unhelpful to the developer...
My own feeling: Python is more AOP ready than java. So lighter-weight
techniques like Michele's decorator should go further. But
methodology not yet formulated.
Michele Simionato
> My own feeling: Python is more AOP ready than java. So lighter-weight
> techniques like Michele's decorator should go further. But
> methodology not yet formulated.
To clarify: my view is that lightweight techniques are enough and
that a general methodology (in the sense of AspectJ) should NOT be
formulated. Not everything should be formalized, give powerful
enough tools to the programmer and let her do her work.
The fundamental flaw underlying AspectJ is the ambition
to put together a monster intended for all uses and purposes.
I could cite some relevant aphorisms, such as "Don't give a man
a fish: teach him to fish" or "Programming languages should be
designed not by piling feature on top of feature, but by removing
the weaknesses and restrictions that make additional features
appear necessary" (Clinger).
Michele Simionato
Steve
I think it might be worth pointing out, though, that there is still
significant interest in AOP in the Java community, in the form or
interest in the Spring Framework. See, for instance:
http://www.onjava.com/pub/a/onjava/2004/07/14/springaop.html
This article was written in 2004. It has taken some time for
awareness of Spring to penetrate the Java community, but it appears to
be happening in a serious way.
-- Thank-god-I-don't-have-to-learn-all-this-Java-superstructure-stuff-
ly yours,
Steve Ferg
Kay Schluehr
> > AOP was a research that gone nowhere - at least not in its orginal
> > AspectJ form ...
>
> I think it might be worth pointing out, though, that there is still
> significant interest in AOP in the Java community, in the form or
> interest in the Spring Framework. See, for instance:http://www.onjava.com/pub/a/onjava/2004/07/14/springaop.html
>
> This article was written in 2004. It has taken some time for
> awareness of Spring to penetrate the Java community, but it appears to
> be happening in a serious way.
Yes, I knew about Spring AOP but didn't keep much attention. Is AOP
used a lot in the Spring context or is it just a fancy, experimental
feature which was just cool to implement at some time?
> -- Thank-god-I-don't-have-to-learn-all-this-Java-superstructure-stuff-
> ly yours,
As I understand Spring it was part of a liberation wave from J2EE in
the Java community: return to POJOs and dependency injection as the
main composition technique. Spring is probably not that bad.
> Steve Ferg