News for hackers. Stuff that matters.
Re:JDK 8 Release Notes by discreteevent on Tuesday March 18, 2014 @06:55PM (#7425632)
Re:JDK 8 Release Notes by hibikir on Tuesday March 18, 2014 @08:39PM (#7426126)
But without a pattern matching system, optional is still half of what it is in, say, Scala.
Re:JDK 8 Release Notes by yummyfajitas on Wednesday March 19, 2014 @12:48AM (#7426873)
Why would you ever pattern match on Option[T] in Scala? In all my code, I do either:

    optionalF.map( _.whatever ).getOrElse(fallback)
or perhaps

    (optionalF <+> optionalFallback).getOrElse(finalFallback)
For those unfamiliar with <+>, see here: http://www.chrisstucchio.com/blog/2014/handle_failure_with_p...
Re:JDK 8 Release Notes by modersky on Wednesday March 19, 2014 @04:06AM (#7427297)
I think that's a pretty extreme position. First, it will run a lot slower than the pattern matching alternative:

    optional match {
      case Some(x) => whatever(x)
      case None    => fallback
    }
Second, I find the pattern matching code much clearer. Sure, it's also longer, but clarity trumps everything.
Re:JDK 8 Release Notes by noelwelsh on Wednesday March 19, 2014 @04:31AM (#7427353)
map / getOrElse is standard in all the Scala code I've seen. Abstracting over the monad is also a pretty big win that has made some big refactorings painless for me. Pattern matching is really only used by beginners IME.
Re:JDK 8 Release Notes by modersky on Wednesday March 19, 2014 @06:04AM (#7427601)
Well, then maybe the beginners do it right? You have not argued against my two points: It's much slower, and less clear.
Re:JDK 8 Release Notes by noelwelsh on Wednesday March 19, 2014 @06:38AM (#7427726)
Clarity comes from familiarity. It's not an objective measure.

The speed benefit is well known, as is the corollary, premature optimisation. I expect checking for null is even faster if speed is the main concern. It's an engineering tradeoff, just like making the abstraction to a monad (or monad plus). In the normal course of events I'm more concerned about flexibility than performance and would prefer the abstraction.

Re:JDK 8 Release Notes by dapz on Wednesday March 19, 2014 @12:29AM (#7426821)
Isn't map/flatMap and orElse enough, if only for Optional?
Re:JDK 8 Release Notes by hrjet on Wednesday March 19, 2014 @03:43AM (#7427255)
It's not enough for compactly expressing imperative logic. In Scala:

  resultOption match {
    case Some(x) => println(x)
    case None => println("error")
  }
Without pattern match:

  if (resultOption.isDefined) {
    println(resultOption.get)
  } else {
    println("Error")
  }
The .get is the problem.
Re:JDK 8 Release Notes by benjiweber on Wednesday March 19, 2014 @05:28AM (#7427479)
There are several ways of doing it concisely with the Java Optional

  import java.util.Optional;

  public class Scratch {
      public static void main(String... args) {
          Optional<String> foo = Optional.of("foo");
          Optional<String> bar = Optional.empty();

          System.out.println(foo.orElse("Error"));
          System.out.println(bar.orElse("Error"));

          foo.map(Print::print).orElseGet(() -> Print.print("Error"));
          bar.map(Print::print).orElseGet(() -> Print.print("Error"));

          foo.ifPresent(Print::print);

      }

      static class Print {
          public static <T> T print(T val) {
              System.out.println(val);
              return val;
          }
      }
  }