Support separate "Generate Getters" and "Generate Setters" #2086
Conversation
CsCherrYY
force-pushed
the
cs-getter-setter-saparate
branch
from
9899d85
to
715c121
Compare
| @@ -92,4 +93,9 @@ public static class GenerateAccessorsParams { | |||
| CodeActionParams context; | |||
| AccessorField[] accessors; | |||
| } | |||
|
|
|||
| public static class ResolveUnimplementedAccessorsParams { | |||
There was a problem hiding this comment.
I would rename it to AccessorCodeActionParams, and it can keep better compatible if you make AccessorCodeActionParams to extend CodeActionParams. Its default AccessorKind can be BOTH.
There was a problem hiding this comment.
Addressed in cf595f6
|
test this please |
| } else { | ||
| Command command = new Command(ActionMessages.GenerateGetterSetterAction_ellipsisLabel, COMMAND_ID_ACTION_GENERATEACCESSORSPROMPT, Collections.singletonList(params)); | ||
| Command command = new Command(ellipsisActionMessage, commandId, Collections.singletonList(params)); |
There was a problem hiding this comment.
Just wondering : If instead of passing params: CodeActionParams you passed a ResolveUnimplementedAccessorsParams, would that help eliminate the 3 separate registered commands ( https://github.com/redhat-developer/vscode-java/pull/2450/files#diff-ca92d1afe836a483259dfc56e55ada3e33076f195fd4f2e7a0fd06be4bfa664f ) on the vscode-java side ? Is it worth doing this ? We pass the kind from client to server via ResolveUnimplementedAccessorsParams to avoid having 3 versions of java/resolveUnimplementedAccessors for each case.
If it's not worth it, this approach is also fine.
There was a problem hiding this comment.
I think it could make our implementation clearer and it's worth doing. I have done it via the new commit cf595f6
Signed-off-by: Shi Chen <chenshi@microsoft.com>
Signed-off-by: Shi Chen <chenshi@microsoft.com>
CsCherrYY
force-pushed
the
cs-getter-setter-saparate
branch
from
a2d21b4
to
cf595f6
Compare
related to redhat-developer/vscode-java#2450
Signed-off-by: Shi Chen chenshi@microsoft.com