[aosd-discuss] Decoupling of Pointcut and Advice concepts

[christopher diggins]

First off I wish to thank everyone who has contributed so far and pointed
out interesting and relevant work, and in general keeping this discussion
interesting and lively.

----- Original Message ----- 
From: "Christopher Dutchyn" <cdutchyn at cs.ubc.ca>
To: "christopher diggins" <cdiggins at users.sourceforge.net>
Sent: Friday, February 13, 2004 5:56 PM
Subject: Re: [aosd-discuss] Decoupling of Pointcut and Advice concepts

> On Fri, 13 Feb 2004, christopher diggins wrote:
>
> > CROSS_CUT target_class AT point_cut WITH advice_class;
>
> > would be more restricting than creating an aspect class which blends
advice
> > with a point cut. Perhaps we misunderstand each other?
>
> I think we have a communication disconnect.  I'm not taking issue with
> abstracting advice_class out from the pointcut.  What I'm concerned with
> is the restriction to a single target_class.  For example, the logging
> aspect would require you to say "CROSSCUT class1 AT <proc calls> WITH ..."
> "CROSSCUT class2 AT <proc calls> WITH ...", repeat with each class in the
> system.

Okay, I follow you now. There would most definitely be a need to repeat that
kind of statement over and over again in that kind of scenario. What are the
alternatives?

We could trivially list a set of target_class within the CROSS_CUT clause  :

CROSS_CUT class1, class2 ... classN AT point_cut WITH advice_class;

Which in of itself is simply a slightly more compact version of what I am
proposing. The next option is to build a language for expressing sets of
classes.

CROSS_CUT class_set_expression AT point_cut WITH advice_class.

So this would be a much more expressive and hence more powerful clause. The
question then is without a facility for expressing sets of classes, can we
still be considered AOP? I think the expression of sets of classes is
important, but not crucial to AOP.

As an aside, I am considering using intefaces as a method to express a set
of classes. i.e. the set of classes implementing interface X. This I think
is a very natural grouping of sets of classes.

>Another example is where two classes need to be crosscut
> together; I think you'd write
>      CROSSCUT subjectClass  AT <update>   WITH <lookup and notify
observer>
>      CROSSCUT observerClass AT <creation> WITH <register with subject>
> These are two parts of the same concern: there is an implicit connection
> between them; but you force them to be separated.
>
> The subject/observer concern is scattered into separate places rather than
> holding together as a single related entity.  I encountered this when I
> implemented (AspectJ-like) AOP using ML functors: they can provide a
> simple form of AOP but they don't scale to multiple, recursive, input and
> output modules.

I don't see how you can not separate these two? Irregardless of the fact
that they are connected, any solution eventually comes down to exactly what
you spelt out, CROSSCUT the subject then CROSSCUT the observer. I don't see
how we could do better than to have two separate statements.

> > I am not sure exactly what you mean by whether my aspects support cflow
of a
> > pointcut in another class. Would you mind elucidating further?
>
> This is a simplified version of an example from Coady's papers on AOP in
> the OS kernel. Imagine I have a service S.s() <notation: means method s()
> in class S>.  I want to log all calls to S.s() that are initiated by a
> specific client C.c().  Sometimes C.c() calls S.s() directly, sometimes
> C.c() calls an intermediary I.i() that then calls S.s().  There is another
> client F.f() that calls S.s() directly, and uses I.i() as well.  <To
> connect this with Coady's work: S==buffer allocator, C==VMpager, F==file
> read, I==prefetcher>.  I want only the calls to S.s() that came from C.c()
> (including via I.i()); anything from F.f() (including via I.i()) shouldn't
> be logged.  In AspectJ-ish syntax, I mean call(S.s()) &&
cflow(call(C.c())).
>
> My observation comes from the question "What does <pointcut> look like in
> "CROSSCUT S AT <pointcut> WITH ... in order to implement the above
> concern?"  I don't see how you can talk about points in the cflow of C.c()
> in the pointcut of an aspect that applies only to S.  You can implement
> the idea above with another aspect on C that keeps a global flag
> indicating whether C.c() is currently executing.  Then your advice_class
> will check the flag.  There's an implicit dependency between the aspect
> setting/clearing the flag, and the aspect checking the flag that isn't
> present in the pointcut.

This is an excellent point. I would need a very sophisticated point cut
language in order to achieve something similar. This would most definitely
lead to some binding of multiple classes within the CROSSCUT clause. I am
glad you pointed it out to me. I will think on that some and maybe I can
come up with a decent proposal.

In your experience (and that of others reading) do these kinds of concerns
occur often when implementing non-trivial aspects?

> Masuhara showed how PE'ing

PE'ing?

> the Aspect SandBox gives that construction in
> his CC2003 paper -- and that's reasonable for a compiler to do. Kiczales
> suggested essentially the same solution for cross-thread cflow tests for
> AspectJ in a previous posting to this - and encapsulated the state within
> a single aspect.

Nice. Just goes to show again what an advanced product AspectJ is!

Christopher Diggins