Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Re: hasmethod/hasfield pointcuts (was: AspectJ + Groovy?)


Interesting... since here:

>  @Introduce(within(bar.*) && hasmethod(* setFoo(Foo)))
>   Serializable makeSerializable;

you are using "within(bar.*) && hasmethod(* setFoo(Foo))" exactly as a type pattern supporting designators and composition. So you kind of already had within and hasmethod used both as pointcut designators (for join point matching) and as type-pattern designators (for type patterns).

> 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

:) I wrote something very similar in the enhancement request I raised against AspectJ this morning to track this issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=86818.

-- Adrian
Adrian_Colyer@xxxxxxxxxx



Alexandre Vasseur <avasseur@xxxxxxxxx>
Sent by: aspectj-users-admin@xxxxxxxxxxx

28/02/2005 13:44

Please respond to
aspectj-users@xxxxxxxxxxx

To
aspectj-users@xxxxxxxxxxx
cc
Subject
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
>  
>
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users


Back to the top