[aspectc-user] Should AOP need a separate compiler ?

[Olaf Spinczyk]

Hi,

On Tuesday, 29. January 2002 11:57, you wrote:
> Hi,
>
> At the implementation level for AOP, AspectC++ provides a separate language
> specification and a compiler for defining and compiling aspects. I have an
> ambiguity in why do we need a separate language specification for
> describing aspects and compile it separately. Are there any issues that can
> pop up if we use the same C++ compiler by defining aspects in C++ ?

I don't see any fundamental reason why there shouldn't be a single compiler 
that produces machine code directly from AspectC++. There are only two 
problems:

1. There are some language features, we would like to provide in the future,
   which require compiling all translation units at once. For instance, 
   pointcuts defined with "reachable" require a static control flow analysis,
   which makes no sense if it is restricted to a single translation unit.

2. You might want to use the transformed source code afterwards. For example,
   you implement a library with AspectC++, but your clients who want to use
   your include files use ordinary C++ compilers.
   Another example is that you might want to apply some other code
   transformation after AspectC++. AspectC++ is not able to implement
   all kinds of aspects that I could imagine. Different weavers with
   different aspect languages could be chained. This requires at least
   a compiler with aspect weaver plugins and an appropriate intermediate code
   representation.

The practical reason for us to use a code transformation system to implement 
the language was, of course, that the AspectC++ transformer/compiler is not 
machine dependant now. The back-end is your favorite C++ compiler.

Does this answer cover all aspects of your question?

Regards,

Olaf