RE: [aspectj-dev] Dynamically defining fields

["Gregor Kiczales" <gregor@xxxxxxxxx>]

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.

One advantage of doing it this way is that you can even consider
writing the generated aspect back into your main source directory,
and then the ajdt tools can help you better understand the structure
and role of the generated fields.



> -----Original Message-----
> From: aspectj-dev-admin@xxxxxxxxxxx 
> [mailto:aspectj-dev-admin@xxxxxxxxxxx] On Behalf Of Keven Ring
> Sent: June 22, 2004 5:54 AM
> To: aspectj-dev@xxxxxxxxxxx
> Subject: [aspectj-dev] Dynamically defining fields
> 
> 
>  I have a software project where we are attempting to 
> allieviate some of 
> the responsibility from the end-user by automatically defining some 
> static, final fields in their code, based on other 
> declarations made in 
> their software.  These declarations are in the form of user-defined 
> methods that follow a particular pattern.  For each method 
> that matches 
> that pattern, we would like to define a field in their class to 
> correspond with that method name.
> 
>  The effect that we are looking for could be provided with C-like 
> pre-processors, however, we are already utilizing aspects for other 
> areas of the project.  Thus, rather than adding a new tool, we would 
> prefer to re-utilize an existing one, in this case, AJC.
> 
>  There are three problems as I see it:
> 1) For this particular problem, we are interested in method 
> declarations, versus method invocations
> 2) We do not need to modify the code in the method 
> declaration, but we 
> want to add code in the class (in this case, primitive class 
> variables), 
> and what we want to add is not known apriori.
> 3) It would be assumed that the users could use the declarations in 
> their code; this has the effect that the code may not compile 
> unless the 
> new code (in this case, additional variables) are included during 
> compilation.
> 
> I would love to be able to write something such as the following:
> 
> pointcut actionMethod(MyBaseClass mbc) : declare (void 
> MyBaseClass+.action*(..)) && target(mbc) {
>  // Get the name of the method
>  String name = thisJoinPoint.getSignature().getName();
> 
>  // Strip off the "action" designator
>  name = name.substring(5);
> 
>  // Declare a variable in this class with the name of the 
> method  thisJoinPoint.addTypeDeclaration("public static final 
> int _"+name+" = 
> 5;");
> }
> 
> 
> To better clarify, suppose one writes code such as:
> 
> public class foo {
>   public void actionSomethingHappened() {
>   }
> 
>   public void actionSomethingElseHappened() {
>   }
> 
>   public void doWork() {
>     switch (waitForAction()) {
>       case _SomethingHappened : ...
>       case _SomethingElseHappened : ...
>       default : System.err.println("What Happened????");
>     }
>   }
> }
> 
> In order for this code to compile, the variables 
> _SomethingHappened and 
> _SomethingElseHappened have to be declared.  In this case, we 
> would like 
> to key off the fact that there is a convention to a method name.
> 
> I recognize that the current bounds of AJC do not support this.  Can 
> this group provide either recommendations on what other tools might 
> provide a similar capability, or, if features such as this 
> are generally 
> usable, we would be willing to take a stab at implementation within 
> AJC.  If this sort of functionality would be a welcomed 
> addition to AJC, 
> I would be interested in finding out
> 1) What the requirements are for submitting code changes to AJC
> 2) Suggested starting points to begin understanding the actual AJC 
> source code
> 3) Any similar or related changes that are either in 
> progress, or have 
> been strongly considered for inclusion (ie, some thought process has 
> already been applied)
> 
> 
> In some regards, this is similar to a request a couple of months ago 
> where getter and setter methods are automatically generated 
> based on a 
> declared field, without knowing the name of the declared 
> field(s) apriori.
> 
> Thanks in advance!
> 
> -- 
> Keven Ring               | "Oh no,  Not Again..."
> The MITRE Corporation    |   Bowl of Petunias -
> 7515 Colshire Drive      |   The Hitchhikers Guide to the Galaxy
> McLean VA 22102-7508     |
> PH: (703)883-7026        |
> 
> 
> 
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx 
> http://dev.eclipse.org/mailman/listinfo/aspect> j-dev
>