[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Re: [aspectj-dev] Dynamically defining fields
- From: Jordi alvarez Canal <jalvarezc@xxxxxxx>
- Date: Tue, 13 Jul 2004 12:36:40 +0200
- Comments: localhost [127.0.0.1]
- Delivered-to: firstname.lastname@example.org
- Fcc: /$FOLDER_MISSATGES$/$FOLDER_ENVIATS$
Hi Keven, I have been working recently in an extension to AspectJ
that probably could help you. The proposal extends AspectJ with
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
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:
No doubt to contact me if you want any further information.
:Gregor Kiczales wrote:
:>As you've noticed, AspectJ won't do this for you
:>In general, ApectJ's code generation facilities are
:>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
:>but I don't know if its written down.
:>A common problem with the kind of code generation you are
:>about is that the generated code is scattered (and
:>a number of files. That can get you into complex compile
:>because you want to avoid having the generator output to
:>So the trick is to have the generator output a modular
:>then let the AspectJ compiler weave the definitions into a
:>of output class files.
:>One way to think about this is as a two stage compiler.
:>stage goes from a high-level statement that the existence
:>methods implies the existence of certain fields, and
:>declaration for each such field, in a single aspect. The
:>then weaves those fields throughout the code.
:You're absolutely right - this would work, assuming that
:stage worked off of _source code_ and not compiled class
:user code may utilize the variables which are to be weaved,
:and thus the
:code will not compile until *after* the weaving has taken
: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
:weaving a .class file. The other choice merges the two
:stages into a
:single process, in effect, creating a 2 pass compiler. I
:correct me if I'm wrong - my compiler theory is a little
: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
:delcare variables, a compiler must resolve references after
:has completed. Given that references are resolved
: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,
:else does?), does AJC only work on code that successfully
:*prior* to weaving, or is it possible to write a method
: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
:it isn't really cross-cutting. I know that there were
:specifically for pre-processor type of behavior. Usually,
:require modifications to the language (eg, added keywords).
: AspectJ is
:at least a post-processor (possibly a pre-processor (in
:least), depending on the answer above), but defines it's
:keeping the java language pristine. Having a tool which
:acts as a
:pre-processor (in effect, at least) without having a
:modifying the language accordingly. Given that we already
:AspectJ for other cross-cutting concerns, we were hoping to
:expand) on some of the other use-cases for which a
:pre-processor may be