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