Dean Wampler's Blog

I posted an extended version of the slides from my QCon San Francisco talk, Radical Simplification Through Polyglot and Poly-Paradigm Programming (PDF). The PDF includes some slides I skipped in the actual talk, for time’s sake.

InfoQ.com may offer a video of this talk. Stay tuned.

An Aquarium user asked recently if you can use after_raising advice to raise a different exception, e.g., to wrap the original exception. Now you can, with the commits I did today. (This change will appear in the forthcoming V0.4.2 release.) Actually, this feature was partially implemented already, but never finished (OOPS!)

The following made-up example illustrates what you can do. Imagine you are one of the handful of Ruby programmers who aren't using ActiveRecord ;) and you have an OracleDriver class that handles Oracle database transactions.

class OracleDriver
  class OracleDriverException < StandardException; ...; end
  class ConnectionError < OracleDriverException; ...; end
  def connect
    if try_to_connect == false
      raise ConnectionError 
    end
    ...
  end
  def find query_parameters
    ...
  end
end

In the application code that uses the OracleDriver you ignore any exceptions raised (because we will implement an exception handling strategy elsewhere...).

  ...
  def load_object oracle_driver, query_parameters
    oracle_driver.connect
    oracle_driver.find query_parameters
  end
  ...

Finally, you implement an application-wide exception handling strategy for any exceptions raised by the driver.

Aspect.new :after_raising => OracleDriverException, 
    :in_types => ... do |jp, object, *args|
  # Ruby needs a standard way to wrap one exception in another.
  original = jp.context.raised_exception
  app_exception = ApplicationException.new(original.message)
  app_exception.set_backtrace(original.backtrace)
  jp.context.raised_exception = app_exception
end

In other words, any exceptions raised by calls to OracleDriver are wrapped in an ApplicationException, which will be thrown by Aquarium when the advice block finishes.

This technique can also be used when handling exceptions in after advice.

By the way, in a similar way, you can also change the return value in after and after_returning advice. In this case, you assign a new value to jp.context.returned_value.

The new V0.4.0 release of Aquarium adds support for JRuby. Not only do the regular “pure Ruby” Aquarium specs run reliably under JRuby (V1.1RC2), but you can now write aspects for Java types with Aquarium! There are some limitations and issues. For details, see my "blog":http://blog.objectmentor.com/articles/2008/02/25/writing-java-aspects-with-jruby-and-aquarium at "Object Mentor":http://blog.objectmentor.com and the "JRuby":http://aquarium.rubyforge.org/jruby.html page at the Aquarium website.

I released V0.3.0 of Aquarium today. The most visible change is a new set of synonyms for many of the parameters passed to API methods, providing a more "English-like" feel. For example, previously, you might declare an aspect like this:

around :methods => :all, :types => [Foo, Bar], :advice => advice_proc

Now you can write the same aspect as follows:

around :calls_to => :all_methods, :within_types => [Foo, Bar], :use_advice => advice_proc

which reads more like English.

Similarly, attribute matching is simpler.

after :attribute => name, :attribute_options => [:readers], :objects => [foo, bar] ...

becomes

after :reading => name, :on_objects => [foo, bar] ...

There are many internal improvements to improve DRY'ness, robustness, and performance.

There should be no upgrade issues, so give it a try!

I've posted a PDF for the presentation I did last night on Aquarium at the Chicago Ruby Users Group (Chirb). I also posted a zip file with three exercises that are adapted from the examples on the aquarium web site.

I will give a presentation on Aquarium at Chirb this Monday evening, Oct. 1st. David Chelimsky will also be speaking on new developements in RBehave and RSpec. Details are here. David and I will be doing a joint presentation at the December meeting. It will be a tutorial on Ruby metaprogramming.

This is primarily a bug-fix release. I labeled it "v0.1.5" instead of "v0.1.1", because a non-trivial API change was required; Aquarium no longer automatically adds methods to Object, due to collisions with Rails. This means that users of the "DSL methods" will need to require a new file or include a new module. See the "CHANGES" file in the distribution of "here":http://aquarium.rubyforge.org/changes.html for more information.

I am pleased to announce the first release of Aquarium, an Aspect-Oriented Programming toolkit for Ruby. I created Aquarium to address a few goals that aren't adequately addressed by other AOP toolkits for Ruby. Most of these goals reflect the issues you encounter when using sophisticated aspects in large systems. First, the most important feature of any AOP toolkit is the "pointcut" language it provides, which is how you succinctly specify the "join points" across a system where behavior changes are required to support the "cross-cutting concern" that the aspect implements. Most people assume that Ruby doesn't need an AOP framework because its built-in metaprogramming facilities make method interception and wrapping easy. This is the "advising" part of an AOP toolkit. However, the real value of AOP is the modularity capabilities provided by the pointcut language. One goal for Aquarium is to match and even exceed the power of the AspectJ pointcut language. I also hope to make it as user-friendly as possible. Next, Aquarium seeks to handle the issues that arise when multiple advices are applied to a single join point, including precedence control. Another goal is the ability to add and remove advice dynamically. For example, you might want to insert troubleshooting advice in a running system, then remove it later when the issue is resolved. The first release already implements this feature, with some limitations. Finally (for now), I want to use Aquarium as a vehicle for experimenting with DSL implementation ideas. For several years, there has been discussion (started by Ivar Jacobson) of the idea that aspects share an affinity with Use Cases (or User Stories), because both concepts cross-cut the application domain object boundaries, in one sense or another. So, if I define a DSL that directly represents a user story, can I map it quickly and efficiently to the implementation objects using aspects? We'll see. There is extensive documentation at the Aquarium site. Please give it a try and let me know what you think!