The jury is still out. I do not believe that you should rush in, take my prototype imlpementation and start using it for real. What I hope to achieve is get smart people thinking about the concept of AOP applied
to a PL/SQL development environment. AOP can be very powerful. Whether the PL/SQL
technology can be AOP-enabled in a viable way is still a question. For AOP to work, there needs to be a blance between development taks and developer’s and project manager’s mentality on the one hand and supporting tools and technology on the other.

However, having said all that, there is no reason why we could not start with AOP for very simple things like logging or debugging. The proof of the pudding…

It seems this was just a strange sort of joke however.

Thanks for your comment. Good to hear from you again.

Like I say in the article, what I am doing here is compile time AOP – or even slightly before compile time, as the source itself is altered. What I mention but do not show in code is that it is not very hard to define the aspects to apply external to the code. So that aspect (no pun intended) is covered. However, as you saw in the examples, it will be impossible to change an aspect and not recompile the advised code (as is the case with Java’s Compile Time AOP solutions. What I have not worked out in a very neat fashion, is how to define the aspects outside of the AOP Processor.

All in all, I wanted to get people – like yourself – thinking about ways forward with PL/SQL. Many good ideas and concepts are being developed in other arenas, like the Java arena, that may very well be applicable to PL/SQL programming as well. Expect my article on Dependency Injection in PL/SQL later this week (I am not kidding you).