Patterns for selecting metaclass will allow better support AOP in Groovy

I'm still being with quantification thoughts for dynamic AOP.

There're some diffirences between dynamic and static weaving implementation. I'm saying about what AspectJ does, and what I'm going to do with Groovy AOP.

In AspectJ, it's focusing on static weaving for better performance. The idea behind is that every dynamic joinpoint has the corresponding static shadow, which is projected on source or bytecode of the target program. All quantifying will be done by AspectJ compiler to match every defined pointcuts, of course, at compile-time or load-time. Easy kinds of quantifiable joinpint are, for example, constructors and methods.

But nothing like this exists when we're talking about dynamic AOP. Dynamic AOP has nothing to do about 'static' shadows. This kind of weaving allows re-definition of aspect at run-time. Dynamic joinpoint in Groovy is powerful and a bit more complex to implement because of its MOP mechanism. Every class in Groovy has its own Metaclass to control the behaviour. ACtually, from AOP perspective, the metaclass can be though of as a basic per-target aspect. But when we're saying about AOP weaving, it allows multiple aspects to weave into a single target class. Comparing with MOP in Groovy, it's clear that AOP is somehow more powerful. In case of my AOP implementation, I have the AOP-metaclass to help dispatching advices.

So what's more ?

To fully support AOP quantification in Groovy, I came up with pattern matching idea to assign a metaclass for the target class. I'm feeling strange with this. I'm thinking of it as a good way to support pointcut-advice AOP model for Groovy. But there's something interesting about it that's beyond my head.

I hope I can figure it out soon.