Show HN: Motif – Scala-like pattern matching with Java 8
1–10 of 36 posts
Re: Show HN: Motif – Scala-like pattern matching with Java 8
#2Re: Show HN: Motif – Scala-like pattern matching with Java 8
#3 public class MatchMap {
private final Optional opt;
private final U defaultValue;
private final AtomicReference result = new AtomicReference();
private MatchMap(Optional pOpt, U pDefault) {
super();
opt = pOpt;
defaultValue = pDefault;
}
public MatchMap whenMatch(Predicate pPred, Function pMapFn) {
if (result.get() != null) {
return this;
}
Optional lFiltered = opt.filter(pPred);
if (lFiltered.isPresent()) {
result.set(pMapFn.apply(lFiltered.get()));
}
return this;
}
public MatchMap whenEquals(T pExact, Function pMapFn) {
return whenMatch(t -> pExact.equals(t), pMapFn);
}
public U resolve() {
return Optional.ofNullable(result.get())
.orElse(defaultValue);
}
public static MatchMap of (Optional pOpt, U pDefault) {
return new MatchMap(pOpt, pDefault);
}
}
The class Match is very similar, but takes consumer instead of Function and has some logic to allow several matches to be executed (if several predicates are ok), or only allow the first match to be executed.Re: Show HN: Motif – Scala-like pattern matching with Java 8
#4http://javaslang.com/javadoc/1.2.0/javaslang/control/Match.h...
Re: Show HN: Motif – Scala-like pattern matching with Java 8
#5Funny, I happened to code something just today very similar, but a lot lighter (just two classes, Match for consuming only, and MatchMap for mapping the optional. No when/get, just a when taking two parameters : the predicate and the mapping function. public class MatchMap { private final Optional opt; private final U defaultValue; private final AtomicReference result = new AtomicReference (); private MatchMap(Option…
Re: Show HN: Motif – Scala-like pattern matching with Java 8
#6- https://github.com/aol/cyclops
- https://github.com/poetix/octarine
- (good ol') http://www.functionaljava.org/
The syntax for these libraries is always a little wonky though. If only these libraries also had some sort of syntax preprocessor to make it more palatable. You could call it, I don't know, Scala, or something.
Re: Show HN: Motif – Scala-like pattern matching with Java 8
#7The Cambrian explosion of java 8 functional libraries like this is fun to watch. Others I've come across: - http://javaslang.com/ - https://github.com/aol/cyclops - http://totallylazy.com/ - https://github.com/poetix/octarine - (good ol') http://www.functionaljava.org/ The syntax for these libraries is always a little wonky though. If only these libraries also had some sort of syntax preprocessor to make it more pala…
Re: Show HN: Motif – Scala-like pattern matching with Java 8
#8Hard to read in comparison to Scala. It's impressive that it was accomplished but some things just aren't meant to happen in Java 8.
I used Scala for 4+ years at a company that spent a non-trivial amount of time and resources speeding up its Scala builds (way more than 2000+ classes), sometimes doing sadly controversial things[1] to achieve that speedup. It was a real quality-of-life issue, and one of the reasons that compelled me to leave.
I'm using Java 8 now, and yes it has its warts and is nowhere near Scala wrt functional goodness, but I'm glad to be compiling and iterating a lot more quickly with the ability to use even a subset of the Scala stuff I missed.
[1] https://groups.google.com/d/msg/pants-devel/mcdllXQsYNg/96ZG...
Re: Show HN: Motif – Scala-like pattern matching with Java 8
#9Re: Show HN: Motif – Scala-like pattern matching with Java 8
#10Hard to read in comparison to Scala. It's impressive that it was accomplished but some things just aren't meant to happen in Java 8.
If you've ever endured the compilation time of a Scala codebase that has more than, say, 2000+ classes, then you might think that some things just aren't meant to happen in Scala either. I used Scala for 4+ years at a company that spent a non-trivial amount of time and resources speeding up its Scala builds (way more than 2000+ classes), sometimes doing sadly controversial things[1] to achieve that speedup. It was a…
(and FWIW I'd say that 2000+ classes - that's what, 600KLOC? - implies a project that should be split up with clear boundaries (i.e. separate release cycles, documented public APIs between them), if only for developer comprehensibility. How big is a Java project that provides the same amount of functionality, and how long does it take to compile? Crikey, 2000 classes...)