Community
Participate
Working Groups
The views that show inheritance (e.g. eclipse type hierarchy, XDE static structure diagram) need to be augmented to show how aspects affect this inheritance structure. For example, if an aspect declares a new parent on a class, the corresponding tree or UML view should show this new link, and should point to the aspect declaration that caused it. A mock-up is attached.
Created attachment 7640 [details] mock-up of a type hierarch annoation
For me - if I know only that graphic - it's not immediately what was actually introduced by the aspect. I assume that it's FigureElement. Is it not possible to add some annotation to the very first line in that case?
This is a really useful addition. Just a few days back, during aTrack development, I wish I had this feature in AJDT. I wasn't seeing an advice being executed and the that part of code was little unfamiliar to me. So I had to perform a search to find out the subaspects. If I had the proposed feature, navigating to those aspects would be so much easier. For certain aspects, support for multiple subaspects need a careful design and having the ability to easily navigate to those subaspects is a step towards understanding the problem (see, for example, AspectJ in Action, page 378-382, where two subaspect implementing transaction management introduce subtle issues).
Here is a suggestion for showing in the outline view how a class is affected by "declare parents". - Model (class declaration) - parents declared by (relation) - declare parents: extends Mumble (declaration on aspect) - declare parents: implements Observable (declaration on aspect) We could have a seperate relation for "extends". However, using the type names in the label communicates the supertypes without adding another relation category. And the target type (i.e. Model) is implicit and not in the label since we're already looking at that type. On the aspect side: - ObserverProtocol (aspect) - declare parents: implements Serializable - declared on - Model We similarly see that the target type is implicit, since it shows up in the "declared on" relation.
Created attachment 13100 [details] Screenshot of editor and outline view. I'm including a shot of how the new outline view looks this morning for declare parents and ITDs. It shows both what it looks like at the declaration side and at the affected class side. (Notice the modifiers for public/private/default access are all reflected in the ITD icons). The changes I've made to AJDE/AspectJ are the minimum I can to get it to work and it seems to be showing reasonable info.
Andy, that screenshot form Comment #5 looking good. It shows all the main structure, and the additional relationship from my Comment #4 are only needed if we're trying to be consistent with an extended Type Hierarchy View. However, this is missing one bit of information that should be really easy to add: whether the decration is adding "implements" or "extends". Just add that to both the link and the declaration labels, as it is done in Comment #4, and it will be more clear what the declare parents is adding. Note that on the target side, it's also nice because it reads similar to the way it would in code, i.e. you see "implements Serializable".
Good observation Mik! I would like to do that ... but ... its not as easy as it ought to be. The attribute attached to a class file that captures the declare parents statement does not record whether it is implements or extends. Everything is treated as extends (try it in a normal program, you can type 'declare parents: Foo extends Serializable' and it will compile just fine). I don't want to modify the attribute definition right now as that would cause a version of AJDT that produced class files that couldn't be processed by command line AspectJ. What I have done is check the types that have been matched. If they are an interface I use 'implements' otherwise I use 'extends'. I'll attach a picture.
Created attachment 13168 [details] Implements/Extends added to decp nodes.
Excellent! Should we differentiate between these two in the ASM? Right now we have: IProgramElement Kind DECLARE_PARENTS But for inter-type stuff we have INTER_TYPE_METHOD, etc. So to make the life of ajdoc and other IDEs easier perhaps we should split that into: DECLARE_PARENTS_EXTENDS and DECLARE_PARENTS_IMPLEMENTS. Whad do you think?
I'm making a UML-like tool that needs to know both the super- and sub-types of a declare parents statement. The declare parents element has a relationship to the target class (the subtype), but it would be great if there was another relationship to relate the declare parents statement to the supertype(s).
This week I plan making the changes needed to address comments #9 and #10. Andy: this should address the work-around you implemented as described in comment #7.
