Lambda the Ultimate

It all depends on what is meant by AOP.

If it requires a contract between an extended component and extending component, then I don't see anything new here.

If it does not... well, how can we live with it? You cannot sue, err, make judgements without contracts :)

I mean things like separate compilation, for example.

What's new in AOP is that it enables a new kind of referencing mechanism in the language. The primary way of saying something in a conventional language is along the lines of "if you want to do X, do A and B and then C on the result of A and B". The intent of aspects is that you want to express something like "whenever P happens, do Q", where P is a declarative specification of an interesting (crosscutting) event. This is very common in natural language.

The technical problem you are alluding to has been adressed by a couple of recent papers, e.g., Kiczales and Mezini at ICSE'05, Aldrich at ECOOP'05, Ostermann, Mezini and Bockisch at ECOOP'05.

For example, the ICSE'05 paper is nice in that it shows that a "contract" in the form of a formal interface does *not* correctly model the interaction between different modules if crosscutting concerns are involved, this whole traditional idea of "contracts and judgements" as you call just it does not work out in conventional languages if you consider crosscutting concerns.

So, the question is not so much whether AOP is bad but whether or not the non-AOP solution to the same problem is worse.

For example, the ICSE'05 paper is nice in that it shows that a "contract" in the form of a formal interface does *not* correctly model the interaction between different modules if crosscutting concerns are involved

Do you refer to this paper?

So, the question is not so much whether AOP is bad but whether or not the non-AOP solution to the same problem is worse.

I saw the author demonstrating that one solution for one problem in one "non-AOP" language is bad. If you also consider that this language (Java) is not known for good typing/modularity, I don't see this proving benefits of AOP.

For example, what is so magical in AOP that cannot be done, for example, using traits (which have better modularity than Java classes)?

Please show me a solution to the problem in the paper in a language with traits (or Haskell or any other non-AO language) that performs better w.r.t. its modularity properties. Traits are fine, but they would not help much in this particular problem. The paper uses Java for illustration but the results would apply equally well to most other imperative or functional languages.

I always hear certain people talking about how "evil" AOP is, but the point is that you need to compare to other solutions of *the same* problem, and not how nice , say, a stack can be implemented with conventional modules. Whether AOP is the best answer to the problem it adresses can be discussed but the existence of the problem cannot be argued away. Show me better solutions with other language means and we can discuss.

So, many people say "AOP breaks encapsulation" or "AOP breaks modularity" or whatever. What I like about the paper is that it shows that is an illusion to think that you would be better off or be in a "safe harbor" with conventional module constructs only.

Show me better solutions with other language means and we can discuss.

I am sorry for not backing up my claims, I meant something along the lines of Aspect-Oriented Programming is Quantification and Obliviousness (barely mentioned on LtU). They mention mixins as a step in history of bringing AOP-like qualities to PLs.

I might try and come up with a concrete piece of code, though I am reluctant to do that at the moment (yes, I know how it sounds).

[on edit: the paper I cited represents my attitude towards AOP: I am not against the idea of obliviousness in general, I just don't the specific implementations and their marketing strategies (i.e., I believe they do not solve the right problem respectivly convey the right message). About "traditional" solutions being wrong: I have seen plenty of them, true. One of my favorite is GEF from Eclipse - it tries to solve AOP-like problem by introducing a complex system of requests, edit policies, commands, etc., in effect building a DSL on top of Java. In a language with mixins a lot of these would be unnecessary, I believe.]

In a language with mixins a lot of these would be unnecessary, I believe.

I quite like the idea of mixins. The only language I'm familiar with that has them, though, is XOTcl. Could you give some pointers to others?

From a Previous Discussion, Oleg expressed concern about aop breaking abstraction. There's been other concerns expressed as well.

For myself, I'm left wondering how a Come From operation is any better than a Go To operation? And I also view AOP as mostly concerned with the Visitor and Observer patterns, and I don't necessarily see aspects as the best approaches to making these patterns easy to use.