= AspectJ Language Design

== User-suggested New Language Features

* `-` wildcard
** https://dev.eclipse.org/mhonarc/lists/aspectj-dev/msg00717.html
** https://bugs.eclipse.org/bugs/show_bug.cgi?id=34054#c2

* Class cast pointcut
** https://dev.eclipse.org/mhonarc/lists/aspectj-users/msg01479.html

* Extensible pointcuts, abstract pointcuts, and interfaces
** https://dev.eclipse.org/mhonarc/lists/aspectj-dev/msg00458.html
** https://dev.eclipse.org/mhonarc/lists/aspectj-dev/msg00467.html +

== Key Language Design Properties

=== Orthogonal join point model

The different kinds of join
points, the different primitive pointcuts, and the different kinds of
advice can be used in any combination.

This was one of the hardest parts of the design to get right, because of
the "constructor must call super" rule in Java. But we finally got this
in 1.0.

=== Pointcuts support composition and abstraction

Abelson and Sussman
say that composition and abstraction are the key elements of a real
language. Clearly the pointcut mechanism is the new thing in AspectJ,
and so it was critical that it support composition and abstraction. The
fact that someone can write:

[source, java]
----
/* define an abstraction called stateChange */
pointcut stateChange(): call(void FigureElement+.set*(*));

/* compose pointcuts to get other pointcuts */
pointcut topLevelStateChange(): stateChange() && !cflowbelow(stateChange());
----

is what makes it possible for people to really work with crosscutting
structure and make their code more clear.

=== Statically type checked

The efficiency, code quality and programmer
productivity arguments for this have been made elsewhere, so I won't
repeat them.

=== Efficient

AspectJ code is as fast as the equivalent functionality,
written by hand, in a scattered and tangled way.

=== Simple kernel

I've heard some people say that AspectJ is too big
and too complex. In the most important sense of simple AspectJ is
simple. I can reason about any AspectJ program with a simple model. The
kernel of AspectJ is simple, and the orthogonality described above means
that its easy to start with just the kernel and slowly add to that.

Its pretty clear to pull out this kernel of AspectJ. I would argue that
the right idea for a standard AOP API
is this kernel, packaged in a way that allows building more
sophisticated tools on top of it.

=== Supports multiple weave times

AspectJ is neutral on whether weaving
happens at pre-process, compile, post-process, load, JIT or runtime.
This neutrality is critical. Its why there are serious JVM experts who
are already thinking about JVM support for AspectJ.

There's more, but I think these are the most important ones. I think any
functionality this group comes up with should also meet these
criteria.