T. Onoma
11/29/2003 8:46:00 AM
On Saturday 29 November 2003 12:44 am, Peter wrote:
> > Thoughts?
>
> I was wondering about something... AOP is based on the idea of join
> points, which you describe nicely in your RCR. There is also a notion of
> pointcuts that select a number of join points - possibly specifying them
> using wildcards - for adding an aspect. This notion is not present in your
> RCR (which didn't occur to me until I read [ruby-talk:86632]). Why did you
> leave it out? With Ruby's large potential for genericity I would expect
> the idea of pointcuts to fit better into Ruby than into Java.
Actually they fit so well we don't even need to explictly deal with them! ;-)
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.
So lets look at a Ruby example:
def aspect_t1(klass)
klass.instance_methods(true).each do |m|
if m =~ /^t/ && klass.instance_method(m).arity==1
puts "Applying advice to #{m}"
klass.class_eval %Q{
def_wrap #{m}
puts "Entering #{m}"
super
puts "Exiting #{m}"
end
}
end
end
end
And I'm sure there are many other ways to go about this. So you see, for Ruby,
implementing aspects and pointcuts really dosen't require anything new, as
long as we have the join-points.
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!
> Also the idea of cflow disappeared. I remember that when they introduced
> it in their tutorial, it sounded weird and unusable, but then they gave a
> quite sensible example of its application. Problem is I can't remember the
> example (things like these get devoured by the black hole in my mind) and
> I can't access my notes until after the weekend. Anyhow, what are your
> thoughts on cflow?
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.
I can tell you that adding these AOP features, convinces me that we need
special keywords for parameter args, keys and block, that all methods have
accessible, despite what's in the method argument list. I.e.
def x(x)
puts args
end
x(1) # -> [ 1 ]
It only makes sense in order to "aspect" methods generically.
-t0