Community
Participate
Working Groups
Add a quick assist/fix "Use in enhanced for loop" that converts an array- or Iterable-valued ExpressionStatement into an enhanced for loop over the expression. Test case: public static void main(String[] args) { Arrays.asList(args); args; } In the first case, the quick assist should be available anywhere in the ExpressionStatement. In the second case, the quick fix can check the binding on the recovered node. Should also work if the ; is missing: public static void main2(String[] args) { Arrays.asList(args) } public static void main3(String[] args) { args }
What's the result that you are expecting here? Also in the second case, can't you simply use the template via content assist?
> What's the result that you are expecting here? The obvious ;-) public static void main(String[] args) { for (String string : Arrays.asList(args)) { } for (String string : args) { } } > Also in the second case, can't you simply use the template via content assist? Yes, that would work, but it's still too much work if you e.g. have the variable in the clipboard already: - type "fore" - Ctrl+Space - Enter - Tab - Tab - find the right variable - double-click, or select using Up/Down and apply with Enter The quick assist also needs a few keystrokes (Ctrl+V, Ctrl+1, <select quick assist>), but only contains 1 mental task (find the quick assist), vs. way too many in the template case: - recall the template name - verify that the right stuff happens when navigating - when you reach the variable field, remember what you wanted to do in the first place...
(In reply to comment #2) > > Also in the second case, can't you simply use the template via content assist? > > Yes, that would work, but it's still too much work if you e.g. have the > variable in the clipboard already: Isn't is possible to tweak the template (or add another one) to work on a selection, just like sysout etc ? The quick assist feels a bit too specialized to me. Also the reasoning in comment 2 assumes that the expression is on the clipboard, however in case this is not true the template route clearly wins.
The workflow of first writing an expression and then using quick fix to do something with it is not that far-fetched, and it's more "object-oriented" than choosing the procedure first. We already implement this in a lot of quick fixes, e.g. assign to local variable, create class/method/field, add cast. To implement this with a template, we would have to tweak the template engine so that it can inject the selection into one of the variables. Otherwise, the secondary variables (element type, element name) that depend on the primary variable (array/iterable) cannot be computed correctly. E.g. add a new variable ${:inject_selection(variable)} that evaluates to nothing but injects the selection into the given variable. So the "foreach" template could look like this: for (${iterable_type} ${iterable_element} : ${:inject_selection(iterable)}${iterable}) { ${cursor} } A complication for the implementation is that the selection can not only be a Java variable that the template variable ${iterable} also finds, but it can also be a complex expression that would have to be added as an additional choice in the resolution of ${iterable}. This sounds like a lot of work for something that can only work for template variables that provide extra support for this new mechanism.
*** This bug has been marked as a duplicate of bug 241696 ***
