Does Ruby need AOP ?

With its strong metaprogramming facilities providing interceptors, hotswapping, mixins and hooks for injecting custom codes, it seems that Ruby developers can very well do without a separate vehicle for addressing crosscutting concerns. Bruce Tate, in his book Beyond Java, has opined that for Ruby developers, AOP is not quite as urgent, because you've already got robust tools to deal with these kinds of concerns ... Another Ruby champion David Heinemeier Hansson of Rails fame, has also expressed similar opinion in the same book:

A standardized AOP framework has never really taken off in Ruby because the language itself already supports most of the desirable functionality of AOP.

MetaProgramming - A Substitute for AOP ?

Never! Metaprogramming can at most be the vehicle for implementing AOP. The most important aspect (no pun intended) of AOP is the semantics, which it enforces for the problems which are supposed to be solved by metaprogramming. AOP is NOT about inserting code snippets at various places, it is about the semantics of abstracting the crosscutting behaviors of an application. The man who brought AOP to the world (Gregor Kiczales) was himself an expert of metaprogramming before and he has the following to say on the semantics of AOP :

Another advantage of a direct semantics for AOP is that it helps with abstraction. When we look at a complex object model, it's simpler to think of it as describing the behavior of the objects, rather than describing transformations on method tables that implement the behavior of objects. The same is true of AOP—it's simpler to think in terms of aspects of an object's behavior, rather than transformations on classes, which transform method tables, which implement the behavior of objects.

So, AOP is all about semantics, abstraction and behavior of the application and is at a much higher level of implementation than the raw power of metaprogramming.

Metaprogramming in Ruby - Too Much Power ?

Metaprogramming operates at a much lower level, empowers developers with too much raw power, which may be too potent for most applications. Let us look at the following snippet from Rails code (adopted from Beyond Java book) :

base.class_eval do
    alias_method :render_without_layout, :render
    alias_method :render, :render_with_layout
end

The code snippet displays metaprogramming prowess of Rails, which implements hotswapping behavior of the base class with improved functionality. But, as discussed above, this is too low a level of abstraction. Using AOP we would have had semantics first - a neat aspect consisting of advices operating on pointcuts. No wonder, Ruby has decided to introduce AOP constructs from Ruby2.

AOP - Only for Statically Typed Languages ?

This is a myth. The real truth is that dynamically typed languages have not yet reached the sufficient level of adoption in the community to feel the need of AOP. Hence Ruby programmers are quite content at the extreme power of meta programming features to implement crosscutting concerns in their applications. Once they reach the maturity in acceptance and we start seeing millions of lines of code written in big enterprise applications, they are sure to feel the need for more abstraction power in addressing the crosscutting concerns. Because of large scale adoption, we have rich tooling support for AOP in Java - when the same happens for Ruby and other dynamic languages we will definitely see the emergence of tools which allow us to program in aspects.

TailPiece

Irrespective of what Gavin King thinks about AOP (he recently snubbed AOP as totally overhyped, failed technology), I am a big fan of aspect oriented programming - recently this technology has delivered a world of good to our team in a Java based enterprise application. But that's for another day, another post ..