Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-dev] Dynamically defining fields 
In the example you have provided, what is the reason for defining the otherwise final static, keyword here being final, variable dynamically?

Are you expecting the waitForAction() to return upredictable results? Otherwise if you know the results before hand, why would you use an additional aspect layer to define such, unless you wanted to reuse such definition across classes which in other way are not related.

If you can provide some more details on what is the puprose of what you are doing, one can analyze such and give you advice based on java's core functionality, as aspects do trap patterned code, redefining your code through aspects, either than enhancing it and providing another angle on reuse of your code would not be efficient and otherwise clear.

Not being judgemental, but just convinced there is a clearer way do to what you need to do, possibly using aspects to generalize such logic, but not to redefine code.

Sincerely,

Artem D. Yegorov

-----Original Message-----
From: aspectj-dev-admin@xxxxxxxxxxx
[mailto:aspectj-dev-admin@xxxxxxxxxxx]On Behalf Of Keven Ring
Sent: Tuesday, June 22, 2004 7: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/aspectj-dev

Back to the top