[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-users] Re: hasmethod/hasfield pointcuts (was: AspectJ + Groovy?)
|
In AspectWerkz (and JBossAOP) the hasmethod/hasfield where used just
like "within"
execution(*.new()) && hasmethod(* setFoo(Foo))
As you say, there was indeed
- a limitation: it cannot match callee side type ("target" static type) ie
call(* new()) && hasmethod(* setFoo(Foo))
is different from
call( (hasmethod(* setFoo(Foo))).new() )
that cannot be expressed using the AW / JBoss version of hasmethod()
- an orthogonality mistake that allowed to adress the use case of the
declare xxx (Mixin) since in that area (in AW at least, don't know for
JBoss) we are using within()
@Introduce(within(bar.*) && hasmethod(* setFoo(Foo)))
Serializable makeSerializable;
Thought I fully agree that hasmethod() is a type pattern, it happens
to be quite insane to write things like that
call( hasmethod(* setFoo(foo))).new())
and going there may indeed lead to have composable (hence named) type
patterns (JBoss has $typedef, don't know how much those are
composable)
Alex
On Mon, 28 Feb 2005 12:01:06 +0000, Adrian Colyer
<adrian_colyer@xxxxxxxxxx> wrote:
>
> > On Thu, 24 Feb 2005 13:11:32 -0800, Ron Bodkin <rbodkin@xxxxxxxxxxxxxx>
> wrote:
> > > (*) I don't think hasfield/hasmethod should be defined as pointcuts
> since it
> > > breaks orthogonality. Instead, these ought to be type patterns, just
> like
> > > Foo+ or annotation matching for type patterns.
> >
> > Hi Ron,
> >
> > Not sure I got what you meant from your comment, but I've implemented
> > the hasfield/hasmethod poincuts in AW and I have a very clear use case
> > for them.
>
> There's an interesting discussion lurking behind these comments which I want
> to try and tease out a little. Firstly let me state the obvious about the
> join point / pointcuts / advice model. There are three components, which are
> separate and orthogonal concepts. Join points are events that occur during
> the runtime execution of the program. Pointcuts are expressions that match
> join points. Pointcuts support abstraction and composition making the
> pointcut 'language' a complete and powerful mini-language in its own right.
> That is to say, the various pointcut designators can be composed (&&, ||, !)
> in many ways to create useful pointcut definitions. Advice is associated
> with a pointcut expression, and executes at each join point matched by its
> associated pointcut expression.
>
> So what?
>
> So, for hasfield() to be a pointcut, we have to be able to answer in all
> contexts and combinations the question "what join points does the hasfield()
> pointcut match?" (Note, it has to be *join points*, not types for example).
> For each pointcut designator we have to able to complete the sentence: "The
> xxx pointcut designator matches any join point where...".
>
> I'm not aware of the semantics that you gave hasfield (for example) in AW,
> but let's look at what it might mean in AspectJ. Suppose I write the
> program:
>
> aspect X {
>
> before() : hasfield(foo) {
> System.out.println("There's a foo field here!");
> }
> }
>
> When does the advice run?
>
> There are a few choices:
>
> * at any join point where 'this' is bound, and the type of 'this' has a
> field named 'foo' (runtime test)
> * at any join point where 'this' is bound and the static type of 'this' has
> a field named 'foo'
> * at any join point where 'target' is bound, and the type of 'target' has a
> field named 'foo' (runtime test)
> * at any join point where 'target' is bound,the static type of 'target' has
> a field named 'foo'
> * at any join point 'within' a type that has a field named 'foo'
> * ... and probably some others.
>
> The most logical choice to me seems to be the last interpretation:
> hasfield(NamePattern) matches any join point arising from the execution of
> logic defined within a type that has a field matching NamePattern.
>
> But the within pointcut already takes a type pattern: within(TypePattern).
> Ron's suggestion that hasfield() should be a type pattern should now be
> clearer. You really want to say something like:
>
> within(hasfield(foo)) == within any type that has a field named foo.
>
> This is using hasfield as a type pattern. Such a usage would also allow this
> type pattern to be used anywhere else a pointcut takes a type pattern too.
> For example:
>
> call(* (hasfield(foo)).*(..)) == any call where the target type of the
> call has a field named foo.
>
> This is the orthogonality point because by making it a type pattern it can
> be composed in many more interesting ways in pointcut expressions. By making
> it a pointcut you constrain the choices.
>
> All this said, for your use case, it seems that you don't want a pointcut at
> all. Instead you are trying to say (in AspectJ syntax):
>
> declare parents : <something here> implements MyMixin;
>
> In the AspectJ language, <something here> is specified to be a type pattern.
> So if hasfield() were a type pattern, you would just write:
>
> declare parents : hasfield(foo) implements MyMixin;
>
> I suspect the DI case also wants the type pattern variation, e.g. :
>
> aspect DI {
>
> Foo foo;
>
> after(Object obj) returning : execution( (hasmethod(setFoo(Foo)).new(..))
> && this(obj) {
> // invoke the setFoo(Foo) method on obj via reflection...
> }
>
> }
>
> How do you envision this working if hasmethod() were a pointcut?
>
> Regards, Adrian.
>
> -- Adrian
> Adrian_Colyer@xxxxxxxxxx
>
>
>
> Michael Nascimento <misterm@xxxxxxxxx>
> Sent by: aspectj-users-admin@xxxxxxxxxxx
>
> 24/02/2005 23:45
>
> Please respond to
> aspectj-users@xxxxxxxxxxx
>
>
> To aspectj-users@xxxxxxxxxxx
>
> cc
>
> Subject [aspectj-users] Re: hasmethod/hasfield pointcuts (was: AspectJ +
> Groovy?)
>
>
>
>
>
> On Thu, 24 Feb 2005 13:11:32 -0800, Ron Bodkin <rbodkin@xxxxxxxxxxxxxx>
> wrote:
> > (*) I don't think hasfield/hasmethod should be defined as pointcuts since
> it
> > breaks orthogonality. Instead, these ought to be type patterns, just like
> > Foo+ or annotation matching for type patterns.
>
> Hi Ron,
>
> Not sure I got what you meant from your comment, but I've implemented
> the hasfield/hasmethod poincuts in AW and I have a very clear use case
> for them.
>
> I wanted to introduce a mixin in any class containing a method with a
> certain annotation. This is the case for genesis (
> https://genesis.dev.java.net , still using AW 1.1, going to migrate to
> AW 2.0 next week ) CommandResolver interface and its default
> implementation. The idea is any class that had a method annotated with
> @Remotable/@Transactional had this interface introduced in order to
> support two core genesis features, transparent remoting and
> transactional support.
>
> Why not requiring the classes to implement a marker interface or be
> annotated at the class level? Well, it feels strange. If a class has
> one or more methods containing one of these annotations, there is no
> point in requiring it to follow yet another pattern just for the sake
> of.
>
> Besides that, this kind of pointcut is quite useful for situations
> when you want to use AOP in existing classes without changing them.
> Not always these classes inherit from the same class, implement a
> common interface or are in the same package, but they may share some
> properties, for example. I can see these pointcuts being useful for
> dependency injection as well, requiring only POJOs to work.
>
> Regards,
> Michael Nascimento Santos
> https://genesis.dev.java.net/
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>