: b ? c : d
Does anybody have a smart way of splitting a sequence of input strings into chunks defined by a marker string. E.g.
Iterator<List<String>> result = List.of("a", "b", "c", "-", "d", "-", "e","f", "-", "g").splitByMarker(x -> x.equals("-"))so that the result would be [["a","b","c"],["d"], ["e","f"],["g"]] ?
.slideBy might work, but then I need to hold an external counter to "switch" to the next list.
var testee = List.of("a", "b", "c", "-", "d", "-", "e","f", "-", "g");
var zero = List.of(List.empty());
var separator = "-";
var result = testee.foldRight(zero, (str, list) -> separator.equals(str)
? list.prepend(List.empty())
: list.tail().prepend(list.head().prepend(str))
)Strange day today, already second time that Java is behaving not as expected...this piece of code should terminate, right?
AtomicInteger ai = new AtomicInteger(0);
List.of("a", "b", "c", "-", "-","d", "-", "e", "f", "-", "g")
.slideBy(x -> x.equals("-") ? ai.getAndIncrement() : ai.get())
.toList();On my system Java (v15, vavr 0.10.3) is not terminating when I run this snippet.
(difference to previous example: I have 2 consecutive "-" in the list)
When I want to remove null value at a vector or steam, in java I use filter objects.nonNull, but in kotlin the IDE is so clever that it keep track on nullable value and will not accept this method. I map the value to an option by flatmap to solve this problem. Is this reasonable to create one option instance for this process or any more clever solution?
var vectorWithNull: Vector<Image?> = Vector.empty()
var vectorNoNull: Vector<Image> = Vector.empty()
vectorNoNull = vectorWithNull.filter { Objects.nonNull(it) }
// Type mismatch. Required: Vector<Image> Found: Vector<Image?>!
vectorNoNull = vectorWithNull.flatMap { Option.of(it) }
// OK!
Stream<String> names = Stream.ofAll(allNames);
Option<String> newName = getNames._1();Above, I am a bit unsure on how to do a .append +getOrElse if the newName option is not defined
elsewhen(bool, () -> a)
.orElse(() -> when(bool2, () -> b))
.getOrElse(() -> c);elsewhen(bool, () -> a)
.else(() -> bool2, () -> b)
.getOrElse(() -> c);- because scala has by name parameters
- because scala has if expressions
- scala hax extension methods
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/Arrays.java#L4556
What's your oppinion in constructs like the following pipeline? What would you prefer and any rationale? My feeling is that option 1 is a better practice somehow, but just a feeling. Any arguments?
Option 1:
Option("helo")
.peek(value -> someEffects(...))
// ... .peek(...)
.peek(value -> moreEffects(...))Option 2:
Option("helo")
.peek(value -> {
someEffects(...)
// ...
moreEffects(...)
})I'm not talking specifically about the Option monad nor .peek() function, but any kind of pipeline like the above: Single lambda vs. Multiple lambdas?
3 replies
List<Either> and my goal is to partition them based on left and right and prepare list out of the values - List<RightValue>, List<LeftValue>I currently use
partition = list.partition(Either::isRight) and then partition._1.map(Either::get) and partition._2.map(Either::getLeft)I am little hesitant to use
get and getLeft directly as they are exception prone. Is there a better idiomatic way ?
1 reply
The following code seems identical to me:
Either<String, Integer> someEither = Either.left("not a number");
assertThrows(ArithmeticException.class, () -> someEither.getOrElse(() -> {throw new ArithmeticException();}));
assertThrows(ArithmeticException.class, () -> someEither.getOrElseTry(() -> {throw new ArithmeticException();}));Is there some subtle difference?
3 replies
Please share best practices around Either and Tryusage:
i.e. say, there's a 'plain java' code for token validation and user authentication:
class AuthCredentials {
// ....
}
class NotAuthenticatedException extends Exception {
// ....
}
class WrongTokenException extends NotAuthenticatedException {
// ....
}
AuthCredentials authenticate(String token) throws NotAuthenticatedException {
// .... validate token, return authenticated credentials
return new AuthCredentials();
// ...or, throw an exception if authentication does not result in credentials
// throw new WrongTokenException();
}'Not authenticated' is not a failure, it's a just another valid computation result (i.e. some wrong token provided as input). So the code should probably be re-written with Either:
Either<NotAuthenticatedException, AuthCredentials> authenticate(String token) {
// .... validate token, return authenticated credentials
return Either.right(new AuthCredentials());
// ...or, return 'not authenticated':
// return Either.left(new WrongTokenException());
}Finally, there also could be actual failures - say, some internal database refused connection, etc. Those are not 'results', but failures. Mixing 'valid results' (like above) with 'failures' does not seem desirable, for the reason they usually handled differently, and by different layers of the application.
So, should the code be further re-written with Try added on top of Either?
Try<Either<NotAuthenticatedException, AuthCredentials>> authenticate(String token) {
try {
// .... validate token, return authenticated credentials
// ................. may throw a 'failure' exception
// ..............
return Try.success(Either.right(new AuthCredentials()));
// ...or, report 'not authenticated':
// return Try.success(Either.left(new WrongTokenException()));
} catch (Throwable ex) {
return Try.failure(ex);
}
}Is it in line with Vavr.io best practices, or clear over-engineering?
Thank you.
1 reply