Community
Participate
Working Groups
HEAD IType#getFields/Initializers/Methods() should define the order of the results in all cases. The class Javadoc already says: "The children are listed in the order in which they appear in the source or class file." For IType#getTypes(), the order is already defined in all cases (including binary without source). The other get<ElementType>s() methods should define the order in the same way.
> The class Javadoc [of IType] already says: "The children are listed in the > order in which they appear in the source or class file." This should be moved up to IMember, such that it also applies to children of other kinds of member.
Could we get this for 3.6?
Jay, can you please see what it would take ? Thanks.
(In reply to comment #1) > > The class Javadoc [of IType] already says: "The children are listed in the > > order in which they appear in the source or class file." > > This should be moved up to IMember, such that it also applies to children of > other kinds of member. Even though IField, IMethod etc. are types of IMember, looks like only an IType can have them as children. In other words IType seems to have a better context to mention about the children and their order. Please let me know if I am missing something here.
Sorry, comment 1 is actually a separate problem, but since this looked like it's only about Javadoc, I didn't want to open a myriad of individual bugs. The Javadocs of IType (specifies the ordering for IType#getChildren()) and IType#getTypes() are already fine. Comment 0 requests to also give the ordering guarantee in the other filtered children getters. I just found that I missed IType#getChildrenForCategory(String) in the initial list, so please add the blurb to that method as well. After this is done, comment 1 requests to give the same ordering guarantees on children of IMember (copy the sentence from the Javadoc of IType so that it applies for all IMember#getChildren()). All other kinds of IMember (namely IField, IInitializer, and IMethod) can also have child elements (currently only ITypes for anonymous types), and these children should be ordered as well.
Created attachment 149490 [details] Proposed Patch Attaching the patch with updated Javadoc.
Markus, Can you please see if the patch is fine?
Jay, please be patient: Markus is on vacation. He's back on November 2.
That's perfect, thanks.
Released for 3.6M4. Thanks Jay. Verification should be done by checking the javadoc.
Verified for 3.6M4. PS: Shouldn't the ordering also be mentioned in the doc for the getters getTypeParameterSignatures() and getTypeParameters(). Although the @return tag specifies the ordering, the main documentation doesn't.
> PS: Shouldn't the ordering also be mentioned in the doc for the getters > getTypeParameterSignatures() and getTypeParameters(). Although the @return tag > specifies the ordering, the main documentation doesn't. That's enough for me. Repeating it in the main doc would just bloat the comment and not add further information.
