Roger Johansson wrote:
> I would argue that is a bit more problematic than just applying the
> pointcuts onto the new methods.
>
> If AOP were only about interception, that would be an all ok approach to
> just apply the cuts as soon as a new method appears.
>
> however AOP != interception
> your aspect might rely on some mixed in state, and that state might be
> the result of a chain of actions done onto the subject.
>
> if a new method is added to the subject, and you re-apply the cuts, you
> would also have to put the mixed in state for the aspect in a valid
> mode.

AOP is not just interception, I agree with you. And the whole of the
propsal certainly atests to that. The idea of cuts is not to supply a
"total AOP framework" but just to provide a common and standardized
foundation for doing AOP in Ruby. Going beyond that starts to push
scope of what this proposal is about. One might argue for a more
complete function, say:

  cut A < C
    pointcut( :someadvice ){ |jp| loaded?( jp.method ) ...
  end

Sure, that can be done. You can do it in pure Ruby. The proposal
doesn't need to go into those details.

I also point out that Cut-based AOP is all about the 80/20 rule. There
are things AOP it purposefully  dosen't address. For instance, local
varaible assignments are not available joinpoints. But capabilities
like that fall into that 20% range. Method interception on the other
hand is 80% range. What happens when we shoot for the full 100% is we
end up with a system that is too complex for general use and too
inefficient in execution.

T.