From: mkersten Date: Mon, 14 Jul 2003 12:58:42 +0000 (+0000) Subject: Finally adding some design docs (after 4 years). X-Git-Tag: V1_1_1~236 X-Git-Url: https://source.dussan.org/?a=commitdiff_plain;h=cc57abb7456100c16eb009707293d41d1f760db3;p=aspectj.git Finally adding some design docs (after 4 years). --- diff --git a/docs/developer/language.html b/docs/developer/language.html new file mode 100644 index 000000000..641353f9d --- /dev/null +++ b/docs/developer/language.html @@ -0,0 +1,194 @@ + + + + + + + +AJDT Project Proposal + + + + + +

AspectJ Language Design

+ +

Key Language Design Properties (from Gregor)

+

(1) 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.
+
+(2) 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:

+
+

/* 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.
+
+(3) Statically type checked. The efficiency, code quality and programmer +productivity arguments for this have been made elsewhere, so I won't repeat +them.
+
+(4) Efficient. AspectJ code is as fast as the equivalent functionality, written +by hand, in a scattered and tangled way.
+
+(5) 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.
+
+(6) 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.
+ 

+ + + + \ No newline at end of file diff --git a/docs/developer/modules.html b/docs/developer/modules.html new file mode 100644 index 000000000..14b8e01b9 --- /dev/null +++ b/docs/developer/modules.html @@ -0,0 +1,222 @@ + + + + + + + +AJDT Project Proposal + + + + + +

AspectJ Modules

+ +

There are a number of different structures [Parnas] : the module structure, +the uses structure, the runtime structure,… We focus first on the module +structure as found in the org.aspectj and org.eclipse.ajdt cvs roots.
+
+The CVS modules are all rooted at dev.eclipse.org:/home/technology.

+ +

Core Modules

+

ajbrowser

+

This module contains the ajbrowser application. It depends on the ajde module +for access to the aspectj compiler, and also for the swing user interface +components that ajde provides.

+

ajde

+

This module hides the details of accessing the aspectj compiler and interpreting +compilation results (error messages, structure model etc.) from other +applications (typically IDEs) that need to invoke it programmatically.
+
+It also contains a library of common swing user interface components that can be +used by any swing based IDE. Ajbrowser and the non-eclipse IDE integration +projects use this library (except for the emacs support).
+
+Note: we need to separate the ajde component into two – ajde.core and ajde.ui. +The core should be independent of the ui component (currently this isn’t quite +true). This will allow non-swing based applications that need to integrate with +the aspectj compiler to do so without needing to provide a swing environment. +The issue is most pressing on Mac OS X where AJDT fails to load due to conflicts +between Eclipse’s SWT and swing
+
+Changing any public interface in ajde can break all the IDE integration projects +and should be done with care.

+

asm

+

This module contains the Abstract Structure Model which represents the result of +an aspectj compilation. Clients of ajde are returned an instance of the +structure model which allows them to navigate and interpret the structure of a +compiled aspectj program.

+

bridge

+

...

+

org.aspectj.ajdt.core

+

...

+

org.eclipse.jdt.core

+

...

+

runtime

+

...

+

taskdefs

+

...

+

util

+

...

+

weaver

+

...
+
+Supporting Modules

+

build

+

...

+

docs

+

...

+

lib

+

...

+

releases

+

...

+

testing

+

...

+

testing-client

+

...

+

testing-drivers

+

...

+

testing-util

+

...

+

tests

+

...
+ 

+ + + + \ No newline at end of file diff --git a/docs/developer/overview.html b/docs/developer/overview.html new file mode 100644 index 000000000..fdd7520d6 --- /dev/null +++ b/docs/developer/overview.html @@ -0,0 +1,174 @@ + + + + + + + +AJDT Project Proposal + + + + + +

AspectJ Design Overview

+ +

Here are some sobering words from David Parnas on +"Ignorant Surgery" in his paper on Software Aging:

+

"Although it is essential to upgrade software to +prevent aging, changing software can cause a different form of aging. The +designer of a piece of software usually had a simple concept in mind when +writing the program. If the program is large, understanding the concept allows +one to find those sections of the program that must be altered when an update or +correction is needed. Understanding that concept also implies understanding the +interfaces used within the system and between the system and its environment.  +Changes made by people who do not understand the original design concept almost +always cause the structure of the program to degrade. Under those circumstances, +changes will be inconsistent with the original concept; in fact, they will +invalidate the original concept. Sometimes the damage is small, but often it is +quite severe. After those changes, one must know both the original design rules +and the newly introduced exceptions to the rules, to understand the product. +After many such changes, the original designers no longer understand the +product. Those who made the changes, never did. In other words, *nobody* +understands the modified product.
+Software that has been repeatedly modified (maintained) in this way becomes very +expensive to update. Changes take longer and are more likely to introduce new +'bugs'"

+

Contents

+ + + + + \ No newline at end of file