-
Bug
-
Resolution: Not an Issue
-
P4
-
None
-
1.2.0
-
sparc
-
solaris_2.5
In member summary tables, members with the same name but different arguments are not sorted in the right order. For example, the 5 "add" methods in Container
currently sort as follows:
add(Component comp, int index)
add(Component comp, Object constraints, int index)
add(Component comp, Object constraints)
add(Component comp)
add(String name, Component comp)
I believe they are in this order because the character comma "," sorts
ahead of a parenthesis ")", which produces the wrong logical order.
They should be sorted as follows, where a method with a single argument
sorts ahead of another method with the same name and first argument but
has more arguments. This order tends to sort them from simple to complex,
which makes them easier to understand:
add(Component comp)
add(Component comp, int index)
add(Component comp, Object constraints)
add(Component comp, Object constraints, int index)
add(String name, Component comp)
Notice this is exactly the same problem we had and *fixed* with sorting members in the index, so perhaps we can re-use the same solution here.
Notice this problem needs to be fixed for both method and constructor summary tables.
currently sort as follows:
add(Component comp, int index)
add(Component comp, Object constraints, int index)
add(Component comp, Object constraints)
add(Component comp)
add(String name, Component comp)
I believe they are in this order because the character comma "," sorts
ahead of a parenthesis ")", which produces the wrong logical order.
They should be sorted as follows, where a method with a single argument
sorts ahead of another method with the same name and first argument but
has more arguments. This order tends to sort them from simple to complex,
which makes them easier to understand:
add(Component comp)
add(Component comp, int index)
add(Component comp, Object constraints)
add(Component comp, Object constraints, int index)
add(String name, Component comp)
Notice this is exactly the same problem we had and *fixed* with sorting members in the index, so perhaps we can re-use the same solution here.
Notice this problem needs to be fixed for both method and constructor summary tables.