Community
Participate
Working Groups
if i have code that looks like this: // ... int cost = 12; int price = 7; setPrice(CURSOR HERE) // ... would it be so hard to deduce that I don't want "cost" auto completed for me, but actually want "price" - as the setter indicates. Now, of course, if there's no "price" available *locally*, then it wouldn't make sense, but if there was then it would..
No, it would not be so hard to handle such a special case. But what about synonyms and other methods which would logically fit into that pattern?
If there are some local fields that could all fit the parameter (because they're of the correct type), then we need to use some sort of strategy to choose the "recommended" (i.e. automatically filled in) field. The current strategy is to choose the first declared local variable. This enhancement request merely suggests that that strategy be enhanced to say take a look at all the local variables (with a valid matching type), and don't just choose the first one, but instead weight them and choose the most likely one. The suggested strategy for weighting them is to weight the one that matches the get/set syntax for the method being auto-completed. Nothing more. If we wanted to extend this weighting strategy, it would be easy to plug in some "weighers" later on once the code was written to make the weighing generic.
Another enhancement that would be nice is to use the most recent variable instead of the first declared one. See the code example below. I know this is getting complicated, but once a tiny filtering mechanism is put into place, it would be straightforward to also have an associated preferences tab that allowed the user to define what rules they prefer to use for this particular auto-complete... private void doSomething() { int a = 2; int b = 3; if (a == 2) { // code assist recommends "b", // although "a" might be more logical setSomething(b); } } private void setSomething(int s) {}
Get rid of deprecated state.
