[aosd-discuss] has and hasfield pointcut expressions

[Ron Bodkin]

> > 2) "A Case for Statically Executable Advice: Checking the Law of Demete=
r with AspectJ" http://www.ccs.neu.edu/home/lorenz/papers/aosd2003lod/ - I =
believe you could use their proposal for statically executable advice to ch=
eck whether a join point shadow has the necessary properties
> > =

> =

> I don't think #2 is applicable as I want to do this stuff and =

> deploy/compile time, not at runtime.  Also the main usecase of =

> has/hasfield is with introductions anyways.

#2 is actually about writing aspects that run at deploy/compile time, so it=
 would be relevant (and they do actually deal with class-level issues). Alt=
hough I think both research proposals are interesting, I don't think they a=
re ready for integration into commercial tools. =


> I cannot get access to the aspectj mail list or #1.  Can you summarize?
> =

> Maybe you mean something like this?
> =

> execution($has{* *. at Asynchronous(..)}.new(..))  where the type =

> expression is enclosed in $has{}?  I didn't like this approach as it =

> quickly became unreadable.
#1 proposes this prolog-style syntax:

?jp matching =

  reception(?jp, withdraw:, <?amount>),
  inObject(?jp, ?obj),
  objectVariable(?obj, balance, ?balance),
  difference(?balance, ?amount, ?afterWithdrawal),
  below(?afterWithdrawal, 0)

Here's a short summary of the AspectJ discussion:
1. To address https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D44365, Jim Hu=
gunin proposed resolutions to two semantic issues and proposed four approac=
hes to extending AspectJ syntax for type patterns to pick out modifiers:

Two were based on what I would call pseudo-attributes:
  @InterfaceType @ClassType @AspectType @InnerType @AnonymousType
  @interface @class @aspect @inner @anonymous

Two were based on a predicate-style:
  isInterface(), isClass(), isAspect(), isInner(), isAnonymous()
  interface, class, aspect, inner, anonymous

He also noted that the increasing complexity of type patterns will increase=
 the desire for typedefs (e.g., using "declare typename: PublicFinalType: p=
ublic final *;").

There was subsequent analysis of the pros and cons of each, including the r=
ecognition that there is a real danger in further complicating the pointcut=
 language (where it uses type patterns). Adrian raised the issue of how thi=
s will interact with supporting annotations, e.g., he posed this cautionary=
 example:

  execution((@TxRequired || @TxMandatory) public (@SessionBean || @EntityBe=
an) (com.myco..* &&
    @BusinessDomain).*(.., at SensitiveData) throws @Auditable) =


  (execution of a public method requiring a transaction, on a business doma=
in object in the =

  com.myco packages, returning an EJB. The method takes a parameter contain=
ing sensitive data, =

  and throws an exception that should be audited). =


All of these factors make me believe adding a kind of typedef for AOP will =
be very valuable, so we can compose and reuse these complicated expressions=
. Heck, even pure Java developers are wondering if it's worth having typede=
fs for use with generics (Cedric Beust raised this issue on a thread on The=
ServerSide recently...)