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

31–40 of 152 posts

Re: Pattern Matching for Java

#31

Post by dkarl »

I feel these new language features that get grafted onto Java end up awkward and unpleasant to use. Java is still Java, and it exacts a stiff awkwardness tax for writing code in a style different from how Java OO was envisioned 15-20 years ago. The examples in the linked article look fine, but the difference between pattern matching as "possible direction" and pattern matching as "new language feature" could easily end up like the difference between Orson Welles as Charles Foster Kane and Orson Welles as Falstaff.

I wonder if Oracle could create some excitement around the platform by creating or adopting a new language as an official repla^D^D^D^D^D "new member of the family" to implicitly succeed Java just like C# replaced Visual Basic for most use cases. Java could be kept around as a sop to die-hards like VB.NET was. It's great that the JVM allows a thousand flowers to bloom, but it's not great that the only "official" choice on the JVM is a language that hasn't been able to evolve very far from its 1990s roots.

Re: Pattern Matching for Java

#32

Post by zerr »

wffurr wrote: post #15
zerr wrote: post #13

Earlier quoted context omitted.

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 f…

Enumerating and testing for type equality each derived classes in one place (i.e. manual type switch) is certainly a bad code practice in OO languages. Yes, the better way is to let virtual method dispatch mechanism decide.

Re: Pattern Matching for Java

#33

Post by zamalek »

holtalanm wrote: post #24
lacampbell wrote: post #20

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...

wow. I havent used C# for at least three years, but that is a really powerful feature.

What's even better is that the DLR consists of some pretty tight code. Historically I was using a ConcurrentDictionary containing Funcs compiled using Expression. I've found the DLR is just as fast (for things that you can express with it), with a much lower overhead. I've started using it in dynamic scenarios wherever possible.

Basically, this is going to be about as fast as you can get with the statically-typed underlying runtime.

Re: Pattern Matching for Java

#34

Post by rattray »

I'm currently thinking through the design of a pattern-matching feature for JavaScript, through a superset I'm building called LightScript[0].

I liked that this article laid out the specific options and various shades of gray that can constitute parts of "pattern matching".

I'm curious for thoughts on a syntax like this:

    x = match y:
      case > 3: () => "it's bigger than three"
      case 2: () => "it's strictly equal to two"
      case Integer: (x) => `some int smaller than two: ${x}`
      case String: (s) => `some string: ${s}`
      case Array: ([ first, ...rest ]) => `a list starting with ${first}`
      case Object: ({ a, b }) => `an object with property a: ${a}`
This is somewhat more difficult given that even when using Flow or TypeScript, there's relatively little type granularity available at runtime.

Any thoughts?

[0] http://lightscript.org

Re: Pattern Matching for Java

#35

Post by aardvark179 »

evdev wrote: post #19

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…

This is not just a hypothetical proposal, I believe there is a working prototype and a lot of thought has gone into this. More things are coming, but pattern matching is a low hanging fruit that doesn't have difficult interactions with the type system or VM. Value classes need a lot of language enhancement to be really useful, and those things are likely to land before value classes themselves.

Re: Pattern Matching for Java

#36

Post by drdrey »

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.

Pattern matching allows far more than just branching by type comparisons. And I disagree that this is bad code style, this is actually a very common pattern in compilers (e.g. when you iterate a list of instructions, which may be of different types)

Re: Pattern Matching for Java

#37

Post by mark242 »

peeters wrote: post #11

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 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 _ =>
  }

Re: Pattern Matching for Java

#38

Post by robohamburger »

lacampbell wrote: post #20

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...

I think matching + destructuring solve similar but different problems. Often times, items you don't need to do something based on some unbounded set of things nor do you need an abstraction.

For example, if I am writing a logic system in rust I can either match with one single arm or a nested match implement simple rules like double negation. I don't see how you could easily do this with multiple dispatch like the one you link.

I find myself really wish more languages would implement both the system you link and something like rust's/ML's. Usually it's easier to build multi-dispatch than match syntax though. In rust you can use HashMaps of TypeId -> Box. I would do a similar thing in C# (though now I am going to use this shiny new feature).

Re: Pattern Matching for Java

#39

Post by taeric »

mark242 wrote: post #37
peeters wrote: post #11

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 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 _ => }

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?

Re: Pattern Matching for Java

#40

Post by nightmunnas »

taeric wrote: post #39
mark242 wrote: post #37

Earlier quoted context omitted.

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 _ => }

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 s…

(String) o;

:)

Post reply on HN