|
Cedric
writes:
I am worried to see
terms such as "screenful" and "file" in a discussion that should be focused
exclusively on
design.
...
I
think a few small errors in my message may have caused my intent to be
garbled.
When I
said file, I meant class. Since many people store the source code of
classes in files, I sometimes switch back and forth.
And of
course I didn't mean to suggest that it didn't make sense for pointcuts to ever
be separate from advice on them. The reason AspectJ lets you put a pointcut
declaration into a class is to make it possible for classes to export libraries
of pointcuts that other advice writers can use. This idiom is one of the key
ways AspectJ supports pointcut reuse. I was commenting on the reason why AspectJ
lets you put them together.
As for
"in a screenful" I'm not sure that's a just tool issue. All I was saying
is that we wanted the language to make it possible for a simple aspect to appear
all together in front of the user easily. Sure you can use tool support to bring
together an aspect that is spread into several places. But if the pointcut and
advice on it are already defined together, then no tool support is even
needed.
In a
later message Cedric writes:
Agreed. I was just pointing out the fact that a case can be made
for both approaches: advice and pointcuts tightly coupled or clearly
separated and reusable independently of each other.
In my opinion, an
AOP framework should provide both.
Which
I believe indicates we are in violent agreement on this
issue.
Gregor
writes:
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.
I am worried to see
terms such as "screenful" and "file" in a discussion that should be focused
exclusively on design.
These terms are related to tools, and they
should not have any bearing on the design of a framework. What you want
is an easy access to this information, and this can be provided by an
IDE.
AspectJ is based on Java, and the fundamental unit of
modularity in Java is the class, so I am really surprised to
read:
From that perspective, putting
pointcuts and advice bodies in separate files isn't what we
want.
Java programmers are
extremely proficient with classes. If you fail to acknowledge this fact,
you are fighting against the language and against its users. Rickard
recently voiced this concern the AOP Alliance mailing-list. Note that he
stressed that this limitation with AspectJ was a problem for him, and he made
it clear that things might be different for other users, but I believe his
concern is valid.
Separating advice and pointcuts in different classes
is even more important in the context of J2EE AOP. Leave it up to J2EE
vendors to provide sophisticated pointcuts so that the users can focus on
writing the business logic of their aspects without worrying about these
low-level details.
And then, leave it up to higher-level tools to
present the developer with a convenient view allowing them to quickly
distinguish pointcuts, join points, advice code in relation to the Java code
they apply to, etc...
In short, use every tool for what it is
specialized for.
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. Glad to hear
that. I believe the semantics of these tags might end up being more
"vague" than the traditional way to define pointcuts: they would be
hints that a weaver might or might not pick. I can see certain scenarios
where tagging the Java code would be more reliable than using a sophisticated
but fragile AspectJ regexp to locate the join point. However, it is
important to keep in mind that metadata fundamentally undermines the original
goal of AOP (separation of concerns) so it should be used very
sparingly.
--
Cédric
http://beust.com/weblog
|
