Java already has simple pattern matching with exceptions (try {throw ...} catch ...). It's surprisingly ergonomic, even though it's just a hack
Pattern Matching for Java
71–80 of 152 posts
Re: Pattern Matching for Java
#72This is nice. But I think my number one feature would be first-class relationships in object oriented languages.
Re: Pattern Matching for Java
#73To me the biggest missing features are not this but:
* heredoc/multiline string/embedded interpolated strings * concise array, map, and object literal initializers. * structural/anonymous types
Simple things like multivalue return become an exercise in boilerplate in Java. As much as I like Immutables.org or @AutoValue, I should be able to return a struct or use destructuring operations at the callsite.
The hack in Java is to use annotation processors to provide nice fluent builder patterns, but really the language should have first class support for this.
Re: Pattern Matching for Java
#74Along with with Value Types [1] Java 10 could be an even more significant improvement than Java 8 was :)
Re: Pattern Matching for Java
#75How does Vavr's (formerly Javaslang) pattern matching hold up? http://www.vavr.io/
Re: Pattern Matching for Java
#76To me the biggest missing features are not this but: * heredoc/multiline string/embedded interpolated strings * concise array, map, and object literal initializers. * structural/anonymous types Simple things like multivalue return become an exercise in boilerplate in Java. As much as I like Immutables.org or @AutoValue, I should be able to return a struct or use destructuring operations at the callsite. The hack in J…
> concise array, map, and object literal initializers.
http://openjdk.java.net/jeps/269 Just a few more month.
Still nothing for the other two, but 1/3 is better than nothing.
Re: Pattern Matching for Java
#77IMO this is the biggest thing available to modern languages that Java is missing. I would absolutely love to see this, particularly pattern decomposition. I wonder if you could do it without something analogous to Scala's sealed classes though--you really want your type checker to be able to assert every match has considered every branch (without having to specify a "default" everywhere). That means you need to be ab…
I mean, reading this article is basically a giant advertisement for Scala and its powerful pattern matching. functionThatReturnsAnyVal match { case i: Int if i > 2 => System.out.println("Greater than 2") case i: Int => System.out.println("Less than or equal to 2") case s: String => System.out.println("Hello, " + s) case _ => }
> reading this article is basically a giant advertisement for Scala and its powerful pattern matching.
Javas strength has always been to take the good parts of its competitors after they've checked out in production (and not just "wouldn't this be a great idea ..?") and implement them. It will probably never be ahead of the curve due to this, but at least it is remarkably free of "looks good in theory, useless in reality"-features.
Re: Pattern Matching for Java
#78To me the biggest missing features are not this but: * heredoc/multiline string/embedded interpolated strings * concise array, map, and object literal initializers. * structural/anonymous types Simple things like multivalue return become an exercise in boilerplate in Java. As much as I like Immutables.org or @AutoValue, I should be able to return a struct or use destructuring operations at the callsite. The hack in J…
> concise array, map, and object literal initializers. http://openjdk.java.net/jeps/269 Just a few more month. Still nothing for the other two, but 1/3 is better than nothing.
Those aren't new language features though, mostly just standardizing Guava conventions into the JDK.
Re: Pattern Matching for Java
#79Earlier quoted context omitted.
> concise array, map, and object literal initializers. http://openjdk.java.net/jeps/269 Just a few more month. Still nothing for the other two, but 1/3 is better than nothing.
Those aren't new language features though, mostly just standardizing Guava conventions into the JDK.
Fair enough, but they do the job. I understand the wish of the designers to not change the syntax if a standard library extension does the job for 99% of the cases. Changing the language syntax is a far more elaborate process.
Re: Pattern Matching for Java
#80I honestly don't need this feature. Am I really the only one? Or do you all just have buckets of source code filled with if instanceof then cast just screaming for this language feature?
I have buckets of code that would be much shorter and more typesafe if it was that way at least.