[aspectc-user] Re: New to AOP !!
mahrenho at ivs.cs.uni-magdeburg.de
Tue Apr 23 12:51:14 CEST 2002
On Tuesday 23 April 2002 09:06, Sanjay Dahiya, Noida wrote:
> One fundamental idea behind AOP is to write find patterns in the code
> (Joinpoints) and write generic code which
> could execute at those joinpoints.
This is what most AOP tools (e.g. AspectC++) do. For me AOP is not limited to
code transformations. It is more like "find patterns in the syntax tree and
apply a transformation under certain circumstances". This includes
transformations of data structures, code sequences (more than just add
wrapper functions and calls to the aspect code).
> The AOP language and the approach at some points seems to be restrictive in
> looking for the patterns. There are many logical patterns in a software
> that one is able to otherwise realize but not detect and operate upon
> programmatically using AOP.
You are right. AspectC++ and (I believe) AspectJ are limited in this point.
But it is more a feature than a bug. Both languages are designed so that you
can easily express a lot of common task as aspects.
In my diploma thesis (sorry, it's in German) I implemented an AOP system that
works more generic (see above). You can do a lot things better (others worse)
with it then with AspectC++, but it is also much more difficult to use. To
use it you need at least a basic knowledge about the C++ grammar and how our
code transformation system (PUMA) works - this is not acceptable for most
users. It is more an infrastructure to build other AOP languages upon. So
some ideas of it went into PUMA and other ideas are planned to become part of
AspectC++ (in the medium-term future) to allow user defined language
extensions (e.g. "exotic" join point match patterns). I'm still working on
the concept because it is more complicated than it looks in the first place.
The major problem is that the system has to guarantee that all things that
you can express with the language lead to valid code transformations.
> These requirements give remind of prolog-like languages where you can pass
> the results of one expression/rule
> into another and filter the results like this.
My approach works more like a sensor-actuator-system on syntax trees (pattern
matching, filter, code transformations, temporary storages). It is written as
a PERL module but looks like a stand-alone language. We name it
> Another similarity I realize is of rule based systems, One philosophy
> behind a rule based system is that the code
> is not the software. It the [code + set of rules about how to use that
> code] combination what make and governs
> how to a software. But rule based approach is presently more inclined
> towards configuring the code for business functionality.
> While working on rule based systems I found some useful applications for
> AOP (Java in this case). but here I feel
> AOP could also use some concepts from rule based approach.
> What I feel is that a mix of approaches here would be of more use, It
> should be the [code + set of rules ] about
> the code which decide how to make a program from a code base. It could be
> how to create/use/destroy the variables, how and whether to throw
> exceptions and in many cases governing the flow of control of the program.
> To achieve such a level of flexibility, a prolog-like language for defining
> rules on the code base to generate a program could be thought of, which can
> provide users with some well-defined patterns and ability to create new
> patterns. A mix of this with well-defined nomenclature for an organization
> or a project can lead to real maintainable and extensible products.
We use a Prolog based system for the system configuration part (selection,
configuration of components, classes, aspects, ...) but not for the AOP part
itself. This is sufficient for our needs.
I will answer to the rest of your mail later. I need some minutes to think
about it (but I'm very busy today). Maybe I could help you so far.
Dipl.-Inf. Daniel Mahrenholz, University of Magdeburg, Germany
More information about the aspectc-user