AOP and pep 246

[Kay Schluehr]

On Nov 2, 5:00 am, "Rustom Mody" <rustompm... at gmail.com> wrote:
> 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, 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.