Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pattern Matching for Java

cr.openjdk.java.net

Post reply on HN
Print view View original

11–20 of 152 posts

Re: Pattern Matching for Java

#11

Post by peeters »

IMO 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 able to mark classes as not-dynamically-extendible, so the type checker has the full set of subtypes available.

Edit: Just got to the bottom of the article. Looks like sealed hierarchies is exactly what they explore.

Re: Pattern Matching for Java

#13

Post by zerr »

raspasov wrote: post #5

Pattern matching is possibly one of the most under-utilized approaches that can simplify a lot of ugly/complex logic.

On the other hand it "prettifies" bad code style - branching by dynamic casts / type comparisons.

Re: Pattern Matching for Java

#15

Post by wffurr »

zerr wrote: post #13
raspasov wrote: post #5

Pattern matching is possibly one of the most under-utilized approaches that can simplify a lot of ugly/complex logic.

On the other hand it "prettifies" bad code style - branching by dynamic casts / type comparisons.

How is that bad code style? That's exactly what virtual method dispatch does.

The authors in the article even address this point, stating that some operations might make sense as instance methods if they are instrinsic to the type hierarchy, but others, especially ad-hoc queries, are extrinsic to the types and best expressed as pattern matching.

Simply calling this "bad code style" sounds a lot like a justification for only having a verbose way to use an alternative to virtual method dispatch.

Re: Pattern Matching for Java

#18

Post by stickfigure »

The syntax still looks tedious compared to Ceylon:

    if (is String name) {
        // compiler knows 'name' is String in this block
        print(name);
    }
    else {
        print("some other text");
    }
Why declare a new variable? The Ceylon syntax works great with union types too.

Re: Pattern Matching for Java

#19

Post by evdev »

IMO the hierarchy of need for this goes:

1 - case classes / value classes / data classes, whatever you want to call them.

2 - match-and-bind syntax

...

11? - fancy pattern matching

This maybe says more about how much I pay attention to what's upstream in Java, but I found the fact that this is just a hypothetical proposal, in April of 2017, strangely shocking. I guess I figured it had to be on the docket for a future java version already.

Re: Pattern Matching for Java

#20

Post by lacampbell »

Why the fixation on pattern matching? Don't get me wrong, I enjoy the benefit it provides, but for OO code multiple dispatch is a more elegant and idiomatic way to solve the "I don't want to implement the visitor pattern" problem.

FYI, I recently found out that C# can actually do multiple dispatch

https://blogs.msdn.microsoft.com/shawnhar/2011/04/05/visitor...

Post reply on HN