Ben Giddings <ben / thingmagic.com> wrote in message news:<3F4CDC9F.1050100 / thingmagic.com>...
> Unless I'm missing something, using blocks in Ruby gets around most of this:
> Instead of "... non-factorizable code specific to f1", just yield to the 
> block given to the function.  Tada!  Or, for a more concrete example:
> 
> module HelperMixin
>    def helper
>        ...
>    end
> end
> 
> class A
>    include HelperMixin
> 
>    def f1
>      helper do
>        ... code specific to f1
>      end
>    end
> 
>    def f2
>      helper do
>        ... code specific to f2
>      end
>    end
> end
> 
> Did I miss the point here?

No. Other people may differ, but to me, as long as the code is
factorized, it's good.

(1) AOP came from the camps of strongly-typed languages, principally
Java. In Ruby and Python there are lot of devices for manipulating
code. Ruby has code blocks, in Python you can pass namespaces and use
exec, or compose multiple functions (in the sense of function
composition as in algebra) to achieve same effect as the before-,
after-, around- advices of AOP. All achieving the goals of AOP in this
example. There are many ways to achieve the same thing.

(2) Yet another approach is using code templates, a la
meta-programming. There are more complicated examples, like the second
example in my previous posting, where it's not easily solved by one
single code block, nor one single MixIn, nor by function composition.
In that case one can assemble the code by using a template, and make
successive pattern substitutions depending on the properties of the
particular instrument. Of course, this approach is a bit beyond the
reach of Java/C++, and anyway the strongly-typed language people would
protest because your code may not have been properly verified by the
compiler.

(3) To me, if the code is factorized, it's good enough. However, if
you have existing code and if you want to add aspects to it, you may
wish to modify the underlying language to expose more "hooks" and
allow more meta-programming features, so that minimal or no changes
need to be done on your existing code. For instance, in your example
above, if you want to add/remove the "helper do... end" wrapper-around
in f2(), you would have to go to the original source code to
add/remove it. At least in AspectJ, the idea is NOT to modify the
original source code, so that you can implement the aspects externally
to the class. (see for instance a Java example in
http://www.voelter.de/data/articles/aop/aop.html)

On the various techniques for achieving AOP (separation of concerns),
there is a paper ftp://ftp.ccs.neu.edu/pub/people/lieber/crista/techrep95/separation.pdf
that mentions the following three techniques: (a) meta-level
programming, (b) adaptive (pattern-oriented) programming, (c) use of
composition filters. In short, there is more than one way to do it. :)

Hung Jung