Bug 241549

Summary: [spec] IType#getFields/Initializers/Methods() should define order from class file
Product: [Eclipse Project] JDT Reporter: Markus Keller <markus.kell.r>
Component: CoreAssignee: Jay Arthanareeswaran <jarthana>
Status: VERIFIED FIXED QA Contact:
Severity: trivial    
Priority: P3 CC: amj87.iitr, daniel_megert, markus.kell.r, Olivier_Thomann, srikanth_sankaran
Version: 3.5Flags: markus.kell.r: review+
Target Milestone: 3.6 M4   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Proposed Patch Olivier_Thomann: iplog+

Description Markus Keller CLA 2008-07-21 11:20:48 EDT
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.
Comment 1 Markus Keller CLA 2008-08-14 06:59:56 EDT
> 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.
Comment 2 Markus Keller CLA 2009-10-13 05:49:58 EDT
Could we get this for 3.6?
Comment 3 Srikanth Sankaran CLA 2009-10-13 06:10:16 EDT
Jay, can you please see what it would take ? Thanks.
Comment 4 Jay Arthanareeswaran CLA 2009-10-13 12:14:04 EDT
(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.
Comment 5 Markus Keller CLA 2009-10-13 13:06:31 EDT
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.
Comment 6 Jay Arthanareeswaran CLA 2009-10-14 02:01:57 EDT
Created attachment 149490 [details]
Proposed Patch

Attaching the patch with updated Javadoc.
Comment 7 Jay Arthanareeswaran CLA 2009-10-23 07:09:57 EDT
Markus, Can you please see if the patch is fine?
Comment 8 Dani Megert CLA 2009-10-23 08:36:14 EDT
Jay, please be patient: Markus is on vacation. He's back on November 2.
Comment 9 Markus Keller CLA 2009-11-03 10:38:56 EST
That's perfect, thanks.
Comment 10 Olivier Thomann CLA 2009-11-03 10:50:37 EST
Released for 3.6M4.
Thanks Jay.

Verification should be done by checking the javadoc.
Comment 11 Ayushman Jain CLA 2009-12-08 04:07:22 EST
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.
Comment 12 Markus Keller CLA 2009-12-08 04:55:06 EST
> 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.