RE: [aspectj-users] Philosophical Questions

["R. Dale Asberry" <lists@xxxxxxxxxxxxxxx>]

> > 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.

Huh?

The terms that Gregor was discussing are related to complexity and not
tools.  Frankly, what benefits will aspects add if they don't significantly
reduce complexity?

> 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.

Again, huh?  What does putting pointcuts and advice in separate files have
anything to do with fighting against Java programmers??

What benefits would be gained by them in separate files?  On the other hand,
doing so would undoubtedly increase complexity.

>
> 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.

You keep making these vague comments without much supporting evidence.  Your
logic is even pointing back on itself...

First you talk about how this enhancement would empower programmers and then
you say, but just leave the tough stuff to the vendors.

>
> 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

In what way is the pseudo-regexp pointcut matching fragile?

> 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.