Community
Participate
Working Groups
20070223 In the following code, invoke code assist after 'get'. Note that 'List' is not yet imported. public class Test { public void test(List l) { l.get } } The proposals seem to be first all methods of java.awt.List, then of java.util.List. But more important would be to have 'get' at first place as it matches the prefix most and I want to select it so the import gets added. 'get' is currently way down in the list
I don't reproduce the problem. For me java.util.List#get() is on the top of the list. The relevance of java.util.List#get() is 34 and the relevance of java.awt.List methods is 30. Do you reproduce the problem with a fresh workspace ?
Hm, you are right. When invoking code assist directly after 'get', the method is in deed the first method. So the real steps should be: public class Test { public void test(List l) { l.ge } } - invoke code assist after 'ge' > 'get' is second last > 'get' has relevance 29 and 'getAccessibleContext' (top entry) has relevance 30 - then, while the code assist window is open enter 't'. > get is still second last Discussed with Dani why the refilter doesn't bring 'get' to from and he said it's important that the proposals are stable and he also trusts that the relevances passed to him in the first code assist. So, what's the reason to let 'get' have a lssser relevance in the beginning? It's the shortest and best match to 'ge', no?
1) get() is less relevant because add this proposal add a warning ("List is a raw type. References to generic type List<E> should be parameterized") and getAccessibleContext() doesn't add a warning. If your project would be 1.4 the relevance would be the same for both proposals. If the type would be List<Object> only java.util.List methods would be proposed. 2) When you complete 'ge' the relevance is 29 for get() as explained in 1). If you add a 't' then jdt/text use the same relevance as before (29). When you complete 'get' the relevance for get() is 33 because the method selector is exactly the completed prefix.
Ok I see. Maybe the relevance penalty is a bit too harsh here. The 'get' is really hard to find after all that other methods. My feeling is that a good prefix matching should be more important than a raw access warning or also a deprecated warning.
get() and getAccessibleContext() have 'ge' as prefix. The relevance penalty for the warning is only 1. That's why the relevance is 29 for get() and 30 for getAccessibleContext(). The only way to have get() on the top the list is to suppress the warning penalty and i think that most of the time the user want to insert a proposal which doesn't add a problem. Currently the only problem concerned by this relevance criteria seems to be the raw type warning. Access restriction, visibility and deprecation are managed by specific content assists options.
You could improve relevance computation by adding a match-length weight i.e. if you type 'ge' then 'get' would be 0.66 while getFoo would only get 0.33.
My thinking was that 'ge' is a 66% match of 'get', but only a 10% match of 'getAccessibleContext'. For 'deprecated' we only have the option 'hide deprecated'. But deprecated elements don't seem to get a relevance penalty.
*** Bug 419619 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
