[aspectj-users] Can I determine method objects or names in advice?

[jmadams@xxxxxxxxx (John M. Adams)]

Dear Friends,

Is it possible to access either the name of the calling method or the
method object in some advice?  I would like to implement something
like the following: Let a be an instance of A and b an instance B.
Let bf be a field of B.  and aMeth be method on A.  If aMethod reads
bf, I want to record that fact so as to reinvoke it later if bf is
updated.

Background:

I'm giving an AOP talk here at the Space Telescope Science Institute
using AspectJ as a vehicle.  As an exploratory project, I am trying to
figure out whether/how I can implement a certain constraint
programming scheme that forms a core substrate of one of our major
scheduling applications written in Lisp using CLOS and the MOP.  Some
Lispy jargon follows, but, given the conceptual ancestry of AOP,
perhaps some knowledgable folks here will know the terminology.

We call this facility COSI, for Constraint Sequencing Infrastructure.
It works roughly like this.  On a special metaclass, we specialize
slot-value-using-class and the corresponding setf in order to 1) track
method invocations that read slots and 2) Cause the method to
re-execute when the slot is updated.  Classes that are to participate
in the COSI scheme use this metaclass, which also introduces some
bookkeeping storage.

There is a macro called defconstraint which is like defmethod but adds
code around the body to establish context so that the slot-value code
can know which method is accessing the slot.

I also need the object accessing the slot, and the object whose slot
is being accessed, but I think I can expose these via pointcut
parameters.

Plain Java has always fallen far short of our needs in the area of
expressiveness.  However, it looks like AspectJ might allow a
COSI-like implementation of considerably more elegance than our CLOS
solution.

We use a system like this to plan observations for the Hubble Space
Telescope.  There are a large number of variables and dependencies to
cope with, which is why we find an automatic propagation scheme handy.

Thanks for any comments you may have.

Best,

-- 
John M. Adams