Implementation of apsectPHP
1. Based on AOPHP 1.0 -- Feb 17, 2005
The first implementation is adapted from
AOPHP uses the RewriteEngine in Apache to redirect all the access to
".php" to a preprocessor "AOPHP" using the "php" file name as its argument.
The output of the AOPHP, becomes the real script processed by the PHP.
The AOPHP processor 1.0 uses a directive "//AOPHP" in the component language to
indicate which aspect will be woven. We believe this gives away the advantage
of aspect-orientation, that is, it should weave the advices without changing
the original source code, not even adding a comment line.
Thus the following code is a slight modification to their implementation. We
assume all the aspects are already located in the same directory, as separate
files "*.aspect". Then the weaver will load all such aspects in sequence, to
weave them with the original code.
In the implemention above, we treat the weaving A1 as a transformation over the
original code, A2 as a transformation over the woven code by A1, etc.
An interesting problem is the order of the weaving.
We copied the "phpport.aophp" into two aspects, and modified the output
to show which one is getting woven earlier. Since we can deal with multiple
aspects now, it is interesting to see this kind of interactions among
AOPHP Says: PHP Cant Talk Right Now
N1: 5 | N2: 10
Aspect2: Before Advice on Add Function Just Called
Before Advice on Add Function Just Called
Aspect2: After Advice on Add Function Just Called
After Advice on Add Function Just Called
TOTAL OF N1 & N2: 15
Although both aspects have "around" advices, only the first one took effect,
because the "say" method already disappeared. The second aspect weaves the
"before" advices earlier, but "after" advices also earlier! The reason I guess
is that the second aspect still weaves its advice with the original function,
rather than on the woven function.
2. Based on the Zend compiler -- Feb 20, 2005
As the current implementation of AOPHP is through textual manipulations of the
callee function in PHP, it is unlikely that the PHP call-site will be
especially when the functions are not inside a script file, but included from
other program files.
Thus an alternative (arguerably better) way is to modify the PHP
compiler/interpretator itself so that all interceptions can be caught.
Fortunately, PHP has an open-source Zend compiler, which can be
modified to support aspects.
Currently, I extend the PHP language with a rather simple aspect syntax,
where an "aspect" is similar to a "class", an "advice" is similar
to a "function" and a "joinpoint" is similar to an "expression".
I haven't implemented "pointcut" (the placeholder for joinpoints) and more
complex "joinpoint" yet, as for now, I think it is enough to try out the
oscommerce case study.
The aspectphp-zend-patch.tar.gz is done on PHP 4.3.10. Simply override the
changed files, and recompile, the modified "php" will recognize and
weave an aspect-oriented PHP program as simple as this component file and this aspect
Any suggestions and contributions are welcome!!!
Mar 3rd, 2005
All aspects are using "*.aspect" naming convention. The original
component PHP code does not need any change.
The woven effect of the simple example is shown.
The changed AOPHP package.
The Windows XP configurations for the AOPHP.
The patch to PHP 4.3.10 (Zend).
The running osCommerce with the following NFR aspect.
The Linux configurations for the Zend.
The phpAspect project
by William Candillon is highly related to the aspectPHP project. The idea
behind phpAspect is to weave the PHP code statically rather than dynamically as
aspectPHP does. Therefore the runtime performance of phpAspect is
better, while the weaving must be carried out at the server side whenever
there is a change to the codebase.
Both projects rely on the true PHP syntax in the YACC grammar. The phpAspect weaver further
uses XSLT to transform on the YACC generated parsing tree in XML form (see the