41–50 of 152 posts
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.
Earlier quoted context omitted.
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; :)
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…
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.
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 e…
You can see it live! [1]
Earlier quoted context omitted.
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.
Project Valhalla (featuring value classes) is scheduled for Java 10 — so it'll probably arrive in production around 2020.
Is this addressed with pattern matching?
Earlier quoted context omitted.
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…
> 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 a…
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...)
Also how the heck do you destructure Java objects with private fields without resorting to bean accessors?