Sure, you could do that (and it would feel natural) but it is not a requirement to get it to work.

One important aspect for AOP seem to be expressions with wildcards to select components and methods to intercept. The approach shown here is focused on single components with explicit methods. Any idea how to make it more generic?

I would love to see full-blown AOP support in Scala, but until then you will have to use AspectJ, AspectWerkz or if you don’t need that power, Spring AOP or similar.

One important aspect for AOP seem to be expressions with wildcards to select components and methods to intercept. The approach shown here is focused on single components with explicit methods. Any idea how to make it more generic?

Actually, I am wiring the interceptors in when I am instantiating the class, not when I define it which means that the target class is actually unaware of the fact that it is being intercepted. Also, this wiring is no different than Spring’s bean factory.

I don’t want to end up in this debate again (we discussed it to death in 2004)

, In any way I did not intend to (re)start a flame war. Sorry.

BTW, I did not mention that the Scala features are quite impressive Thanks for sharing these

Cheers.

Just to mention that this feature is not exactly what AOP solves. I mean, in the way you presented it, you need the explicitly specify the advices when launching a class … thus breaking the master goal of AOP, i.e. classes should be unaware of the advices around them.

Actually, I am wiring the interceptors in when I am instantiating the class, not when I define it which means that the target class is actually unaware of the fact that it is being intercepted. Also, this wiring is no different than Spring’s bean factory.

However, I agree that this is not AOP its most pure sense, since the interceptors are hardwired to a specific component interface.

So IMHO there is no way to do real AOP without a container such as Spring.

I don’t want to end up in this debate again (we discussed it to death in 2004). My view back then was that proxy based AOP (like Spring) was not to be considered “real” AOP like AspectWerkz and AspectJ, but I have loosened up a bit on the religion since then. Getting older (and more pragmatic) I guess.

Just to mention that this feature is not exactly what AOP solves. I mean, in the way you presented it, you need the explicitly specify the advices when launching a class … thus breaking the master goal of AOP, i.e. classes should be unaware of the advices around them.

So IMHO there is no way to do real AOP without a container such as Spring.

cheers.

I don’t know of any way to implement completely generic interceptors/advice in Scala. Then you have to bring in a “real” AOP framework.

I have successfully tried Scala with AOP Alliance interceptors driven by Guice or Spring as well as AspectWerkz aspects, not tried AspectJ though.

The problem with Guice and Spring is that the interceptors are not type-safe, but are using reflection. This is the problem that Rickard’s abstract schema addresses, which (if I remember correctly) Spring AOP supports as an optional strategy when you need type-safety, statically compiled code, direct access to the method arguments etc. and can live with tighter coupling and less flexibility.