Closed mickaelistria closed 3 years ago
Can one of the admins verify this patch?
cc @jcompagner
Lgtm - could we get a test for the new code? There are some other tests for either here:
could we get a test for the new code?
Done.
Just a note that there is also Either3
, where a three-argument overload for map
would probably make sense.
Anything else I should do to complete this PR?
Anything else I should do to complete this PR?
What do you think about @pisv remark?
Just a note that there is also Either3, where a three-argument overload for map would probably make sense.
What do you think about @pisv remark?
I think it's right, but I don't plan to work on this case right now as I don't see usage of Either3 in LSP4E for the moment. So that would be another patch later maybe.
What do you think about @pisv remark?
I think it's right, but I don't plan to work on this case right now as I don't see usage of Either3 in LSP4E for the moment. So that would be another patch later maybe.
No worries. For the sake of API consistency, I'll take care of it after this PR is merged. Thank you for the contribution. (+1 from my side.)
@eclipse-lsp4j-bot ok to test
@mickaelistria I've also tried to run the build for this PR locally (using ./gradlew build
) and it fails with EitherTest.java:16: error: package org.junit.jupiter.api does not exist
. Can you please take a look at it?
is that not a matter of changing this import import static org.junit.jupiter.api.Assertions.assertEquals;
to just
import static org.junit.Assert..assertEquals;
@eclipse-lsp4j-bot run tests
@jonahgraham The local build completes successfully now. Not sure what happens with our Jenkins PR Build. Strangely, the test result does not even include tests in the org.eclipse.lsp4j.jsonrpc.test.json
package. Can you please help?
@jonahgraham The local build completes successfully now. Not sure what happens with our Jenkins PR Build. Strangely, the test result does not even include tests in the
org.eclipse.lsp4j.jsonrpc.test.json
package. Can you please help?
I suspect you are using Java 11 locally? The build machine uses Java 8 as there is a Java 8 requirement. I don't know whether there is an actual requirement to stay on Java 8 or not.
I suspect you are using Java 11 locally? The build machine uses Java 8 as there is a Java 8 requirement. I don't know whether there is an actual requirement to stay on Java 8 or not.
Yes. Got it. Thanks for the clarification and your help!
I tried to Java8-ify this test, but I would really appreciate if LSP4J can move to Java 11 in a near future. Java 8 is really a burden that doesn't make sense to keep bothering with (unless LSP4J has some major contributor really needing this and contributing enough to balance the extra effort).
Java 8 is really a burden that doesn't make sense to keep bothering with (unless LSP4J has some major contributor really needing this and contributing enough to balance the extra effort).
I just created #547 - we should at least know why we are still on Java 8.
Many case of usage of Either in LSP4E involve turning Either into a value. That requires some boilerplate: declare variable, if/else.
This constructs can allow for instance replacing
LSPEclipseUtils.toOffset(textEdit.getLeft().getRange().getStart(), document); else { Position replace = textEdit.getRight().getReplace().getStart(); Position insert = textEdit.getRight().getInsert().getStart(); Position start = replace; if (replace.getLine() > insert.getLine() || replace.getCharacter() > insert.getCharacter()) start = insert; return offset == LSPEclipseUtils.toOffset(start, document); }
by
insert.getCharacter()) start = insert; }), document);
which better captures the logic.