From: Peter Vanbroekhoven <calamitates@...>
Date: 2005-10-20T21:01:24+09:00
Subject: Re: [ANN] [RCR] Cut-based AOP

On Thu, 20 Oct 2005, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: [ANN] [RCR] Cut-based AOP"
>    on Wed, 19 Oct 2005 08:56:59 +0900, "Trans" <transfire@gmail.com> writes:
>
> |This is to "officially" announce an RCR that I posted to RCR archive
> |two days ago. I realize the RCR itself is a bit dense and techincial,
> |so (with thanks to ES) I thought it might be a good idea to provide a
> |little summary and some examples of what it's all about and why it's a
> |such a good approach to AOP for Ruby.
>
> I understand the basic idea.  How about introducing a new method
> e.g. "preclude" that works to intercept the methods in the target
> class/module, instead of cut.  It would be a counterpart of "include"
> for mix-in.

Hi Matz,

This is indeed an option we have considered, and not completely dismissed 
either. Trans just asked me yesterday whether I could add this on top of 
cuts. I think part of the reason that we came up with cuts was because it 
is more like subclassing. One argument that I remember is that a class 
creates a wrapper around its superclass, and can actually adapt to its 
superclass. However, a mix-in cannot adapt to the class it is included in, 
because it can be included in many classes and it can't cater to all their
needs. Likewise a superclass cannot adapt to its subclasses. Because the 
idea of a wrapper adapting itself to the class it wraps is appealing, but 
can only be done if it can wrap only a single class. Hence the idea of a 
cut, and not just module 'preclusion'. I don't know what your thoughts are 
on this.

Does this mean you like the general idea, of just slipping a module or 
class into the class hierarchy and put the wrapper methods there? This 
could possibly be used with the :before and :after syntax you've proposed, 
with a little extension that allows naming the layer it should go to:

   class Foo
     def foo
       p :foo
     end
   end

   class Bar < Foo
     def foo:wrap:Layer
       p [:foot, :before]
       super
       p [:foot, :after]
     end
   end

All these methods could end up in an (autovivified?) 'precluded' module, 
overwrite only methods in that module, and this module can be retrieved 
for more fun.

This is just an idea that was floating around in my mind. The syntax (in 
case you don't like it) is not the point though, the idea is.

Peter