From: Peter <Peter.Vanbroekhoven@...>
Date: 2003-11-30T00:26:18+09:00
Subject: Re: Underpinnings of Method Wrapping

> I originally had a small paragraph touching on this, but I took it out b/c I
> realized that the much of the methods/ideas/terminology used in AOP, as it is
> commonly understood, derives from the fact that Java is the "common
> denominator" implementation language, which isn't a dynamic language like
> Ruby. Hence they had to implement whole new constructs which they gave funny
> names ;-) An *aspect* for instance is nothing more than a method for
> describing where (pointcuts) and what (advices) to insert.

I now realize that my question was phrased a bit badly... The idea of
applying the same advice to multiple methods - implemented using either
the pointcuts from AspectJ or Ruby's dynamism - is an important part of
AOP, and I missed the mention of that in your RCR. I was wondering whether
you thought it was either very obvious or not a very good idea. Our recent
discussions on wrapping kind of made it sound like you believe a wrapper
is often highly specific for a method. If that is so, then indeed wrappers
should be removed on primary method definition, but then wrappers won't
apply to many primary methods either - unless to a method and its subclass
overridden versions.

> But that brings us back to your idea for method "indicators", and now I think
> it would be a really really good idea!
>
>   def meth:arbitrary_symbol
>   end
>
> The indicator would become another property of Method class like arity, and
> used to "group" methods by some classification. They would provide a flexible
> way to determine pointcuts. And an important reason NOT to use def meth:pre
> syntax!

In this incarnation, the idea of those "method indicators" reminds me of
the class selector in CSS; even when HTML tags have the same name, they
can be formatted differently depending on the class specification.

> Honestly, I didn't quite get cflow. So maybe you can help me out here. It's a
> way to further contrain pointcuts. But based on what? Based on runtime
> parameters? What is it doing differently? Given the above, i'm not sure we
> need it, anyway.

cflow basically allows you to say that advice only applies to a method if
it is called directly or indirectly by another method. Suppose you'd want
to do some profiling by counting the number of times a set of methods is
called, but only when the method calls are "triggered" by your own code.
Then you'd add advice to the profiled methods, but it only applies when
they are called directly or indirectly by your own methods, i.e., when it
is in the control flow of your own methods. Does that make sense? But I
need to check the tutorial hand-outs for the example they gave.

Currently it seems to me cflow is only useful for the "meta-tasks" like
profiling and statistics, but maybe you see more general use.

Peter