RE: [aspectj-users] Re: hasmethod/hasfield pointcuts (was: AspectJ + Gro

["Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>]

Adrian gave a great exposition on the concepts suggested by my brief aside.
And to be clear I do think hasfield/hasmethod is useful (as in my original
posting, I think it is especially valuable in a language wih more dynamic
types). 

I also (agree) that AspectJ type patterns are getting quite complex and ugly
even without using adding hasfield/hasmethod; the syntax for picking out
types with annotations is complex. I think having named type patterns and
being able to use them without having to use declare parents when you just
want to pick out a set of objects would be quite useful. 

That being said, if we have type patterns there's the old problem from
AspectJ 1.0.x declare parents: when you match a join point with such a
pattern, what is the type of, say this? Presumably it's Object, and you need
to use reflection to invoke the method/access the field. One pattern that
would avoid the ugly reflection would be a pattern like:

Public aspect FooInjector {
    private interface SetFooable {
        void setFoo(Foo);
    }

    declare parents: hasmethod(public void setFoo(Foo)): SetFoo;

    after() returning (SetFooable instance) : execution(SetFooable+.new(..))
{
        instance.setFoo(someFoo);
    }
}   

-----Original Message-----
From: aspectj-users-admin@xxxxxxxxxxx
[mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Michael Nascimento
Sent: Thursday, February 24, 2005 6:45 PM
To: aspectj-users@xxxxxxxxxxx
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