RE: [abc] Open modules revised

> If, however, all aspect-base interactions are to occur
> through such interfaces, it would be rather difficult to
> write inherently invasive aspects for debugging and tracing
> (as you would have to explicitly expose the points to which
> these aspects would apply). As many of the current uses of
> AOP seem to revolve around such aspects, I believe that any
> method for aspect composition would have to allow for such
> aspects to be written easily. Invasive aspects are the main
> motivation for the more 'dangerous' features (such as open
> and expose) of the openmod extension.

Ok, but could you not always just open a module or create a new one
which exposes the joinpoints of interest to such a (e.g.) logging
aspect? One could also argue that this gives you some modular control of
saying what should be logged at all. Another converntion could be that a
pure aspect (whatever that really means in the end) is always allowed to
see everything cause it is not invasive.
 
> There are some aspects of openmod that I am rather
> Another is the fact that openmod is a pure source-level
> compile-time construct, primarily because pointcuts are pure
> compile time structures as well. They are dissimilar from
> method signatures in that once all the aspects have been
> woven, pointcuts disappear (only their residues remain).
> There might be some advantages if we could compile modules
> into something like java interfaces, with the pointcuts still
> recoverable.
> This does bring up the issue of how to represent pointcuts.
> Perhaps it would be similar to what ajc does to support
> separate compilation.

Well, I am sure that you could for instance store the AST of a pointcut
in a bytecode attribute or something like this.

Eric
Received on Wed Mar 29 18:21:03 2006