Community
Participate
Working Groups
Build Identifier: 20100617-1415 I would like to have the ability to sort members by nearest reference. Currently, I believe that members are sorted alphabetically, but if method x() calls method y(), I would like to have method y() appear immediately after method x() if they are both methods of the same class. Reproducible: Always
I don't think this makes too much sense. The Call Hierarchy is better for revealing such information. Markus to decide.
Yes, I agree that when dealing solely with method calls that using the call hierarchy information rather than references would be better. However, if you are to sort fields, you may want fields declared closest to the method that references them. On the other hand, it is common to group fields and methods separately in a class, so perhaps it is better just to sort methods. (In reply to comment #1) > I don't think this makes too much sense. The Call Hierarchy is better for > revealing such information. > > Markus to decide.
>On the other hand, it is common to group fields and methods separately You can already do this, see Java > Appearance > Members Sort Order.
Thanks for this. What I am suggesting would be a second tier of sorting. For example, methods themselves would be sorted by how "related" they are in terms of calling relationships. Methods that are more "related" would appear closer to each other. Right now, the sorting is done alphabetically, which I think is pretty useless since the outline view can give you that. In fact, perhaps the outline view should also have an option for this kind of sorting. (In reply to comment #3) > >On the other hand, it is common to group fields and methods separately > You can already do this, see Java > Appearance > Members Sort Order.
(In reply to comment #4) > In fact, perhaps the > outline view should also have an option for this kind of sorting. I do feel the need for this kind of sorting in outline view from time to time. (In reply to comment #1) > I don't think this makes too much sense. The Call Hierarchy is better for > revealing such information. Use case: If there is a public method which uses (calls) a couple of private methods, I do prefer to have the private methods just above (or below) the public method so that I can (possibly) see them together in the editor and also they appear together in the outline view (on disabling the alphabetic sort). In the editor the methods may not fit in one screen so you still have to scroll, but this would be pretty useful in the outline view. Though I think this kind of sorting may be hard to implement - for example in the above use case, what happens if 2 public methods use the same private method?
(In reply to comment #5) > (In reply to comment #1) > > I don't think this makes too much sense. The Call Hierarchy is better for > > revealing such information. > Use case: If there is a public method which uses (calls) a couple of private > methods, I do prefer to have the private methods just above (or below) the > public method Yes, I also prefer this. In fact, this is how I learned Java. Horstmann's Core Java books always had methods close together like this and I felt that it really helped me understand his examples. > so that I can (possibly) see them together in the editor and also > they appear together in the outline view (on disabling the alphabetic sort). > > In the editor the methods may not fit in one screen so you still have to > scroll, Yes, but I think that this is still helpful. That is, you know you don't have to scroll far to get what you want. > but this would be pretty useful in the outline view. Though I think > this kind of sorting may be hard to implement - for example in the above use > case, what happens if 2 public methods use the same private method? Yes, I think that this is not as straight-forward as it may first appear to be. In the case you point out, perhaps we would need to move the two public methods closer together as well, since they use common private methods. This may be an interesting research topic (not sure, but maybe).
