Summary: | Provide UI for showing call graph affected by flow advice | ||||||
---|---|---|---|---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Mik Kersten <mik.kersten> | ||||
Component: | IDE | Assignee: | Mik Kersten <mik.kersten> | ||||
Status: | NEW --- | QA Contact: | |||||
Severity: | enhancement | ||||||
Priority: | P5 | CC: | aclement, adrian.colyer, eric, ramnivas | ||||
Version: | 1.2 | ||||||
Target Milestone: | --- | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Mik Kersten
2004-01-29 20:10:08 EST
Created attachment 7639 [details]
mockup of cflow advice showing up in the outline view
That looks good for a first approch, I think. However I see two general problems: Firstly as you know a static cflow analysis is impossible. That in mind, one can easily see that the call hierarchy search that Eclipse uses at the moment is very rudimentary sinc eit just works on declared types and does not even try to approximate the runtime type. So I don't really know how useful such information could be, if one in a lot of cases must fear the information to be wrong. However I tried to integrate some more sophisticated analysis for Elipse last summer but did not finish them due to lack of time. Secondly: Usually we always have a correspondency between advice and adviced methods. One can always go back and forth using the annotations. However for a cflow I guess nobody would really want to annotate all the methods that could possibly be in a specific control flow. That would lead to some kind of inconsistency, though not a big one I have to admit. |