From: Peter Vanbroekhoven <calamitates@...>
Date: 2005-10-21T06:12:08+09:00
Subject: Re: module-based AOP (was Re: [RCR] Cut-based AOP)

On Fri, 21 Oct 2005, Eric Mahurin wrote:

> So, let's start with the simple preclude/wrap module concept.
> Make that the basis instead of "cut".  Implementation-wise it
> may be very similar to what's needed for "cut".  If possible,
> management of these precluded/wrapped modules could be
> provided.

It's obvious that you don't like cuts (you've stated such before). That's 
fine. But we do like cuts. But I don't quite understand what you find so 
complex about cuts and so simple about preclude modules.

One of the reasons I like cuts is maybe best explained with a comparison. 
Say I want to wrap some goods using a plastic wrapping. Given that all 
these goods are about the same size, I can use the same kind of wrapping. 
But given that these goods have different shapes, the wrapping will have 
to folded differently each time. So now make these goods different 
classes, the wrapping a module and the wrapping in different shapes cuts. 
So even if the module is reusable, you often want it to adapt to the class 
it cuts (or precludes). A single module cannot adapt to multiple classes 
just like that, it can have only a single set of methods. A cut is 
essentially an instance of a preclusion if you will, which can adapt to 
the class it cuts, but it can still reuse the module by including it. And 
I'm sure this can be accomplished with just preclusion alone --after all, 
Ruby is a powerful language-- but in our opinion the use of a cut is 
cleaner. And note that this adaptation is important, as this is what is 
needed to handle things like pointcuts specified through wildcards.

Now if you don't want to go through cuts, we can provide a method that 
simply precludes a module, sure. But I want to keep cuts in there because 
they provide us with a clean, simple way to differentiate advice for 
different class even if it is reusing functionality from a module. We 
found it so important that it deserves to be a separate concept. A cut 
potentially gives you a handle on a preclusion itself, specific for the 
class it is precluded in, and it could serve as an entry point for 
call-backs that are needed to have advice react to each class it is 
advicing. Basically, a module can be used for functionality that is shared 
(which is what mix-ins are for), a cut can be used for functionality that 
is specific to each class the advice is applied to, and mix-ins can again 
be used to build that class-specific functionality.

If Matz rules that cuts are not acceptable and precluded modules are, then 
so be it. But as I see it, it will make a common AOP practice more 
involved and less clean. Opinions may vary though.

Peter