RE: Re: [aspectj-dev] Dynamically defining fields

[Jordi alvarez Canal <jalvarezc@xxxxxxx>]

Hi Keven, I have been working recently in an extension to AspectJ 
that probably could help you. The proposal extends AspectJ with 
parametric aspects.

For example, you can define formal parameters in a "parametric" 
aspect based on method patterns. Then you can provide any language 
definition (fields, methods, classes...) in which these formal 
parameters take place.

The proposal was presented in RAM-SE'04 (look for the paper by 
Jordi Alvarez):

http://www.disi.unige.it/person/CazzolaW/RAM-SE04.html

In this workshop you will also find another proposal (by 
Kniesel/Rho/Hannenberg) regarding generic aspects with quite 
similar ideas but a different syntax.

Unfortunately, none of the implementations is available yet.


You can also find some (old) slides regarding my approach at:

http://aosd.net/2004/extravaganza.php


No doubt to contact me if you want any further information.

regards,
Jordi


:Gregor Kiczales wrote:
:
:>As you've noticed, AspectJ won't do this for you
:automatically.
:>
:>In general, ApectJ's code generation facilities are
:limited. That
:>was done intentionally. The AspectJ focus is on AOP.
:>
:>But there is a way that AspectJ may be useful to you as
:part of your
:>solution.  Several people have done this before, so its
:not novel,
:>but I don't know if its written down.
:>
:>A common problem with the kind of code generation you are
:talking
:>about is that the generated code is scattered (and
:tangled) across
:>a number of files.  That can get you into complex compile
:structures,
:>because you want to avoid having the generator output to
:the original
:>sources etc.
:>
:>So the trick is to have the generator output a modular
:aspect, and
:>then let the AspectJ compiler weave the definitions into a
:number
:>of output class files.
:>
:>One way to think about this is as a two stage compiler.
:The first
:>stage goes from a high-level statement that the existence
:of certain
:>methods implies the existence of certain fields, and
:generates a
:>declaration for each such field, in a single aspect. The
:second stage
:>then weaves those fields throughout the code.
:>  
:>
:You're absolutely right - this would work, assuming that
:the second 
:stage worked off of _source code_ and not compiled class
:files, since 
:user code may utilize the variables which are to be weaved,
:and thus the 
:code will not compile until *after* the weaving has taken
:place.
:
:Given this. there are two choices (maybe more?).  One is
:that each stage 
:is a separate process, the first parsing the source code
:and creating an 
:aj file, the other process would then parse the source
:code+aj, and 
:weaving a .class file.  The other choice merges the two
:stages into a 
:single process, in effect, creating a 2 pass compiler.  I
:assume (please 
:correct me if I'm wrong - my compiler theory is a little
:rusty!) that 
:ajc (and javac for that matter) is a two-pass (or at least
:a 1.5 pass) 
:compiler.  That is, because there is no requirement in java
:to forward 
:delcare variables, a compiler must resolve references after
:the parsing 
:has completed.  Given that references are resolved
:after-the-fact, I 
:could imagine that a reference be artificially created
:during the first 
:pass, and successfully resolved in the second pass.
:
:The question becomes (to which I don't know the answer,
:perhaps someone 
:else does?), does AJC only work on code that successfully
:compiled 
:*prior* to weaving, or is it possible to write a method
:that won't 
:compile, and an aspect that completely overrides that
:method, run ajc on 
:the source+aj, and produce a valid .class file?
:
:I recognize that this is not the "usual" use case for
:aspects, because 
:it isn't really cross-cutting.  I know that there were
:tools designed 
:specifically for pre-processor type of behavior.  Usually,
:these tools 
:require modifications to the language (eg, added keywords).
: AspectJ is 
:at least a post-processor (possibly a pre-processor (in
:effect, at 
:least), depending on the answer above), but defines it's
:own language, 
:keeping the java language pristine.    Having a tool which
:acts as a 
:pre-processor (in effect, at least) without having a
:pre-processor, and 
:modifying the language accordingly.  Given that we already
:utilize 
:AspectJ for other cross-cutting concerns, we were hoping to
:utilize (or 
:expand) on some of the other use-cases for which a
:pre-processor may be 
:used.
:
: