Re: Underpinnings of Method Wrapping

On Saturday 29 November 2003 04:26 pm, Peter wrote:
> > 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. 

The join-points are the only thing required to facilitate all of this. So I 
did not think it neccessary to elaborate on. I will go back a mention it 
though. Just to be clear, the method I used with "Ruby's dynamism" provides 
pointcuts. Its not that Java has pointcuts and Ruby doesn't. Only that Ruby 
doesn't need special syntax to do pointcuts (in fact it probably would be 
more limited even if it did).

> 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.

Not exactly, they can be both, and the whole spectrum inbetween. This is a 
tough question. Take for instance a common form of doing very simple 
plug-ins: subclassing. When you make a subclass you'll redefine some methods 
to get the new behavior desired. When you do this, if the wrappers in the 
superclass in any way effect function, then "99 times out of 100" the 
wrappers will have to go. But if they're just to observe, like logging, then 
you may still want them, you may not. In the end, I think we really need to 
support both scenarios. My problem though, is that most people only see the 
logging abilities of AOP, and don't realize there's much much more you can do 
with it, so they think, "of course keep the wrappers", but when you really 
start to take advantage of AOP's power to do more than this, that's when 
you'll start thinking, "why do I have to keep flushing these wrappers!". 
Moreover, not flushing them by default, will only promote the idea that AOP 
is only good for logging type applications. So I think it much better to 
flush by default --we can still offer "table clothing" with a simple extra 
keyword.

> > 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.

That's it exactly. Anyone who's done a lot of html work knows the advantage of 
CSS. This would give that same advantage to Ruby's AOP features.

> > 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.

This reminds me of an RCR I put in once. I suggested that every object have a 
keyword reference back to its "brith parent". So if I cerated object foo = 
Foo.new from within object bar, foo#parent would reference bar. In this case 
it seems their might be good reason for each method to have a keyword method 
(Method#cflow) referenceing the method object it was called from. In that way 
I think we could offer cflow support.

I think a lot of this is pointing to the simple fact that Ruby needs to make 
its Methods more capable and introspective, much in the same way that 
classes/objects are. For instance, cflow, and my suggestion for built-in 
keywords for args, keys and block, plus a way to see what class/module the 
method is in (from the inside out, we can already do from the outside in), 
and so on. Having such capabilities helps exploit the full potential of AOP.

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

I cann see it to some degree: off the top of my head: If the method #kill was 
called from method #hunt, then you might want to trigger the method 
#excitement, but if the same method #kill was called from #protect_thyself, 
then it should instead trigger #relief. Very abstract, but I think it paints 
the proper idea.

-t0

P.S. So what did you think of the singleton foundation?

--------------------------------------------------
 Ethics 101: Don't RIP without proper Props