Bug 292262 - Add more static language interpretations
Summary: Add more static language interpretations
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement with 6 votes (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-14 10:02 EDT by Matthew Adams CLA
Modified: 2013-06-24 11:04 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Adams CLA 2009-10-14 10:02:12 EDT
See discussion on email list:
http://www.nabble.com/A-little-pointcut-help-please-to25807470.html

That discussion boils down to the ability for declare error to allow for more statically determined conditions, for example:

if(!thisEnclosingJoinPoint.getPackage().equals(thisJoinPoint.getPackage()))
Comment 1 Andrew Clement CLA 2009-10-14 11:55:02 EDT
see if there is time in 1.6.7 to do anything
Comment 2 Andrew Clement CLA 2010-03-22 15:36:59 EDT
I'm looking here at what we could do for static analysis.  There are two options:

1) dynamically load the code generated for the if after determining all references within it can be satisfied statically, and execute it.  We would have to conjure up the tjpsp/tejpsp to pass to it.

2) hard code for the common patterns in the if().  Basically converting the Java Ast to a much more simple Ast for a mini-language that we would allow.  This could then be evaluated directly without loading anything dynamically.

I am leaning towards option (2) because it feels easier and I don't like directly executing code I'm compiling as part of the compilation/weaving process.  For option (2), support would be provided for:

constants: primitives plus string
operators: ! && || == != .equals()
entities: thisJoinPointStaticPart/thisEnclosingJoinPointStaticPart

the example in the raise request isn't actually valid as there is no getPackage() method on thisJoinPoint.  Instead it would be:

thisJoinPoint.getSignature().getDeclaringType().getPackage()

that suggests we want support for no-arg method invocations.

Putting all that together would be enough to do some interesting stuff, but I really don't know if it is sufficient.  Think I'll ask on the mailing list for more input on what users would like to say in a deow if.
Comment 3 Matthew Adams CLA 2012-10-01 11:21:34 EDT
Hey guys, target milestone on this says 1.7.0 (as of 2012/10/1).  Any chance to get this into the schedule?
Comment 4 Andrew Clement CLA 2012-10-01 12:19:43 EDT
yes, I haven't done the 'move' yet for 1.7.0 issues > 1.7.2, I might do that today.  If an issue has some kind of target then it is a candidate for getting worked on (if you don't have a target, it *really* isn't high on the priority list)

This feature is a bunch of work, however, so I'm really not sure when we'll find some time. This would be a good little self contained project for a student or someone interested in getting to grips with AJ, maybe we can find someone.
Comment 5 Matthew Adams CLA 2013-04-02 10:10:35 EDT
Any change on this issue?
Comment 6 Andrew Clement CLA 2013-04-02 11:02:37 EDT
not yet.
Comment 7 Andrew Clement CLA 2013-06-24 11:04:16 EDT
unsetting the target field which is currently set for something already released