Community
Participate
Working Groups
From my explorations with starting the tool support for ITITs in AJDT, the main problem seems to be that there is no easy access to fully qualified types when building up the structure of the ITD inner class in the target type. So, given this aspect: aspect F { class Foo.Bar { pubic static final String x = "9"; pubic static List<Date> filterDates(IFilter filter) { // are ITIT methods evan allowed??? ... } } } (I'm not sure if ITIT methods are even legal. If they are not, just ignore them.) There is an IProgramElement corresponding to Foo.Bar. I would like there to be some sort of data structure inside it that describes its member fields and methods. This could be a map with the key being the name of the method/field and the value being the resolved type signature, eg Ljava.lang.String; for a field with type String, or (Lcom.foo.IFilter;Z)Ljava.util.List<Ljava.util.Date;>; for a method that takes an IFilter and an int and returns a List of Dates. So the above would have a map something like this (please excuse the Groovy syntax): [ "x" : "Ljava.lang.String;", "filterDates" : "(Lcom.foo.IFilter;Z)Ljava.util.List<Ljava.util.Date;>;" ] It's easy enough for AJDT to figure out if something is a method or a field based on the signature. Although this may be time consuming to create and memory consuming to store, I'm not expecting that ITITs will be so widely used that creating this map would have a major impact.
> There is an IProgramElement corresponding to Foo.Bar. I > would like there to be some sort of data structure inside it that describes > its member fields and methods. I have yet to check but your description makes it sound like there is a bug in that the hierarchy builder hasn't built a structure for the inner type. I would expect there to be one inside the one for aspect F, just like for a regular inner type. I don't see any reason for new kinds of maps or other data structures - the intent of the structure model is to capture the structure.
Well, that may be true (I haven't checked that). The structure may already exist and that may be sufficient. I would need access to fully qualified names. And also, isn't AspectJ now discarding model elements that are not directly involved with crosscutting (at least when the minimalModel flag is set)? We would need to make sure that these model elements are never discarded to save space.
Looking more closely now, and yes, the children of the ITIT do exist as expected. However, there is no access to fully qualified types. I was hoping that something like IProgramElement.getFullyQualifiedName() would return something useful, but it returns null in this case. In other parts of the code that similarly need to access fully qualified names, AJDT dips into the org.aspectj.weaver.World object. This is a bit messy and I'd prefer not to do it, but it should be possible.
> And also, isn't AspectJ now discarding model elements that are not directly > involved with crosscutting (at least when the minimalModel flag is set)? We > would need to make sure that these model elements are never discarded to save > space. Aspects and their component parts should never discarded even under a minimal model strategy - these intertype inner types should persist. > I was hoping that something like IProgramElement.getFullyQualifiedName() > would return something useful, but it returns null in this case. I can look at doing something there.
Re: > I was hoping that something like IProgramElement.getFullyQualifiedName() > would return something useful, but it returns null in this case. which program elements would you like it to work for? Don't say all.
ping. Andrew can you comment on my previous question?
(In reply to comment #5) > Re: > > I was hoping that something like IProgramElement.getFullyQualifiedName() > > would return something useful, but it returns null in this case. > > which program elements would you like it to work for? Don't say all. I need the type signature for the field/method. Probably getFullyQualifiedName() is not an appropriate place to put this. I only need this for the fields/methods of ITITs. A getTypeSignatureMethod() would work for me. It would return null unless this was an IPE representing a field/method of an intertype inner type.
Much of this is already there, but there is one change I'd like to make as I'd prefer not to make the model any larger for return type handling. What do you currently do with the result of getCorrespondingType() - currently it behaves inconsistently across fields and methods. For a method declared 'List<String> foo()' it will return 'java.util.List<java.lang.String>' but for a field 'List<String> foo' it will return 'List<String>'. ie. in the field case you get what was in the source, in the method case you get the resolved entities ? If you can tell me what you are expecting, that will help me define it one way or the other. Also, do you use getCorrespondingType(true) ever? And signatures are better for you than names, you'd prefer Ljava/util/List<Ljava/lang/String;>; rather than java.util.List<java.lang.String> ?
OK,based on our discussions, lets start with this... program elements already have a method called 'getParameterSignatures()' that returns a List<char[]>, each entry being a parameter signature. I've reworked getCorrespondingType to be consistent but it still returns names and not signatures. The method getCorrespondingTypeSignature will return the signature form. This converts the name to a signature on each invocation so won't be free but that is a better trade off than consuming a bunch of new memory by making the model larger. try them out and let me know (these changes have been committed into AJDT).
Thanks. I'll have a go at this tomorrow.
current changes seem to be sufficient
