[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [aspectj-users] Philosophical Questions
|
Title: Message
Assuming I understand what you mean by marker interface, then I think
mean property based pointcuts are often, but not necessarily
different.
For
me, classic property-based pointcuts are:
call(public * com.us.foo..*.*(..))
execution(CertainValue *.*(..))
args(.., ParticularValue, ..)
In
other words, they are a way of using wildcards that are extremely stable,
because they are based on a deep and stable property of the join points.
The first, public interface, is one of the best examples.
As I
see it, both property-based and enumeration-based pointcuts have complete
non-invasiveness (aka obliviousness), and that is a key property. You don't have
to touch the target source to be able to write the pointcut and advise
it.
Attributes or tags, ala JSR-175 do require access to the target source,
and this is one of their limitations.
Now
what about marker interfaces. If the marker interfaces are already there, in
other words you don't have to go add them before you write the pointcut and
advice, then I would claim that those are property based pointcuts. They have
the non-invasiveness property.
So
some ways of using marker interfaces probably fall into the notion of
property-based pointcuts, and others don't. I guess these concepts crosscut each
other.
Gregor,
Just
so I understand your terminology: property-based pointcuts involve selection
via marker interface and enumeration-based pointcuts involve explicit class
patterns?
This
is an interesting change in view. My impression from following AspectJ lists
before is that metadata and even static inner aspects are still the same
close coupling we had before, only adjacent to the mainline code instead of
embedded within it. Is this just a measure of practicality, or is there some
real benefit to highlighting aspects directly in Java classes? I can certainly
see it easing the transition for developers, but I'm worried that it can get
out of control quickly. If you look at the .NET metadata usage for XML
binding, for example, there are so many metadata tags that it distracts from
the underlying code.
Cheers,
Merrick
One of the guiding principles of the AspectJ design
was that we were trying to enable modular implementation of crosscutting
concerns -- aka aspects. That is what led us to put pointcuts, advice and
other member declarations together into aspects. For example, being able to
see the entire ObserverProtocol aspect in a single screenful of code was
important to us. It gave us the nice modularity we were after. I
personally believe that is critical, that's what separation of concerns is
about, getting the concerns into separate modular
pieces.
From that perspective, putting pointcuts and advice
bodies in separate files isn't what we want.
But what I don't understand is to what degree tool
support will be able to bring the separate things back together. One of the
claims about XML and meta-data is that of course you'll never edit the raw
meta-data or XML, there will be tool support. If there is tool support, then
that support might be able to make things look more modular. But then again,
everytime I see someone talking about XML they insist on showing me the raw
XML, so I'm not sure how present the tool support is.
3) What role, if any, should metadata play in AOP?
I know Gregor has commented on the use of
metadata a couple of times, but the JBoss group is charging ahead with
their "AOP" product which encourages developers to use class metadata to
load library aspects. This strikes me as wrong in many ways, but the
message that is reaching the development community is that interceptors
and metadata are all you need to do AOP. Is this just a function of what's
easy to implement, or are people really having trouble grasping the
concepts?
My opinion on this has softened.
I now believe that meta-data support (ala JSR-175) is useful, and that when
it appears in Java, tools like AspectJ should support it instantly. I think
programmers should use attributes (aka tags or metadata) in pointcuts in
certain circumstances when property-based or enumeration based pointcuts are
not appropriate. Without going into detail, I think the 3 cases
are:
- if the pointcut reaches a large number of
join points, use a property based pointcut
- if the pointcut reaches a small number of
join points, and a property-based pointcut is hard to write, use
tags
- if the pointcut reaches a small number of
join points, and a property-based pointcut is hard to write, and you don't
have access to the target source, then use an enumeration-based
pointcut.