[taeric]

This still seems a terrible example just to try and avoid naming an object. Isn't the comparison to:

    Object o = functionThatReturnsAnyVal();
    if (o instanceof Integer) {
        Integer i = (Integer) o;
        if (i > 2) {
           System.out.println("Greater than 2.");
        } else {
           System.out.println("Less than or equal to 2.");
        }
     } else if (o instanceof String) {
        String s = (String) s;
        System.out.println("Hello, " + s);
     }

I get that the case syntax is kinda nice, but this particular example just doesn't seem to get there for me. Roughly half the lines, which is good. None of them hard to reason about. Which makes it a wash.

Or is the comparison to something else?

[emef]

> I get that the case syntax is kinda nice, but this particular example just doesn't seem to get there for me. Roughly half the lines, which is good. None of them hard to reason about. Which makes it a wash.

I suppose it's a matter of opinion, but to me the comparison of these two snippets is nowhere near "a wash". The readability of the former is leaps and bounds ahead of the java version, and it will only be more apparent as the example grows in complexity.

[taeric]

As either example grows in complexity, they both wash down to a check and a call to another method to do the heavy lifting. In that case, the length of the methods will not grow apart from each other heavily.

And let me be clear. My gripe is only with the example. Not the idea. I happen to like pattern matching, but have never used it like those. Usually I use it to tease apart data by parts. (though, to be fair, I have found I use it less than I thought I did. Not sure why...)

[mark242]

In reality my function would rarely exist in the Scala world since having a weakly-typed return like that is cringeworthy to say the least. But it's better to see this in action with Scala options.

  val myOptionalVar: Option[String] = functionThatReturnsOption()

  myOptionalVar match {
    case Some(str) if str.length > 10 => System.out.println("This is a long string.")
    case Some(str) => System.out.println("This is a short string.")
    case None => System.out.println("This code would be fifteen lines of null checking in Java.")
  }

[pvorb]

With Java 8 having Optional and Lambdas, this is no longer the case:

  final Optional<String> myOptionalVar = functionThatReturnsOptional();
  
  final String output = myOptionalVar
    .map(str -> str.length() > 10
      ? "This is a long string."
      : "This is a short string.")
    .orElse("This code would be fifteen lines of null checking in Java.");
  
  System.out.println(output);

[tylerpachal]

I think this is less-rare than you think. In my Scala code, I have a lot of matching on weakly-typed values which come from parsing JSON objects (where I also deal with a lot of optional values).

[chairmanwow]

I think the prettier syntax actually really helps write code faster. A similar form of syntactic sugar appeared with lambda expressions. Instead of needing to explicitly subclass and write out the overriding method, you can just create an anonymous function.

It's way less code and it makes the resulting code easier to reason about. The code's intent is more elegantly conveyed.

[nightmunnas]

(String) o;

:)

[taeric]

Fair. :) I was much more worried about if I had the required spaces at the beginning of the line, than if I wrote this correctly. Still a static error, though, that the compiler would catch.