Earlier quoted context omitted.
On the other hand it "prettifies" bad code style - branching by dynamic casts / type comparisons.
I disagree. What's bad about that/what's the alternative?
vtable of regular dynamic dispatch.
Pattern Matching for Java
61–70 of 152 posts
Re: Pattern Matching for Java
#62Would be really great to see this make it's way into the language. Here are some ways I've found to work around its absence: * adding a match() function to a common base type. So if it could have subtypes Foo(x), Bar(y, z), then the signature would look like: T match(Function foo, BiFunction bar); * in the cases where I don't have control over the common base type, I've written a builder pattern that constructs a seq…
Just use another language if you want pattern matching so badly. Twisting Java to look like Scala doesn't do the language justice.
Re: Pattern Matching for Java
#63Earlier quoted context omitted.
> FYI, I recently found out that C# can actually do multiple dispatch But also good to know, that it can be costly and unsafe. `dynamic` is basically using reflection at run-time, which for most cases is fine, but it's something to keep in mind. It also means that type checking is delayed until run-time instead of compile-time.
A dynamic type is probably just implemented as a tagged bit of data, surely. Which is the exact same way an algebraic datatype would be done. So I dunno why it would be any slower. I think the safety thing is a non issue as well - what arguments could you pass in to the statically typed function that would cause the use of dynamic to bite you in the ass?
> A dynamic type is probably just implemented as a tagged bit of data, surely
A dynamic "type" is really just `object` whose methods are looked up at run time. It's not tagged data at all. See [1] for more info, specifically the example(s) at the bottom, as the reflection code is what gets executed at run (albeit with caching so that methods aren't looked up all the time).
`dynamic` is a complex feature that enables multiple dispatch as a side-effect, but only because it allows a whole lot more.
[1]: https://visualstudiomagazine.com/Articles/2011/02/01/Underst...
> what arguments could you pass in to the statically typed function that would cause the use of dynamic to bite you in the ass
public void Output(int value);
public void Output(Person person);
...
dynamic aValue = "Some String";
Output(aValue);
Re: Pattern Matching for Java
#64IMO 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 _ => }
You mean it's a giant advertisement for ML and its powerful pattern matching?
Re: Pattern Matching for Java
#65Earlier quoted context omitted.
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 und…
> I've found the DLR is just as fast... with a much lower overhead
Can you expand on this? I would not have expected that it would be faster than compiled expressions.
Re: Pattern Matching for Java
#66Earlier quoted context omitted.
A dynamic type is probably just implemented as a tagged bit of data, surely. Which is the exact same way an algebraic datatype would be done. So I dunno why it would be any slower. I think the safety thing is a non issue as well - what arguments could you pass in to the statically typed function that would cause the use of dynamic to bite you in the ass?
> A dynamic type is probably just implemented as a tagged bit of data, surely A dynamic "type" is really just `object` whose methods are looked up at run time. It's not tagged data at all. See [1] for more info, specifically the example(s) at the bottom, as the reflection code is what gets executed at run (albeit with caching so that methods aren't looked up all the time). `dynamic` is a complex feature that enables…
I am talking about what value you could pass into the multiple dispatch code in the article I linked to. I know you can cause run time type errors using dynamic in general, but in the code I linked it was very well contained and water tight.
Dynamically typed languages usually represent objects as something like a struct with an int tag to represent the type, and a void pointer for its value. The actual reflection going on in the code I posted for multiple dispatch would surely be nothing more than an int comparison - same as what Ocaml probably does.
Re: Pattern Matching for Java
#67I was originally very happy to hear pattern matching was coming to C#, but I don't think it is actually that useful a feature without discriminated unions/sum types too.
Re: Pattern Matching for Java
#68I was originally very happy to hear pattern matching was coming to C#, but I don't think it is actually that useful a feature without discriminated unions/sum types too.
What C# has now is better described as fancy form of Destructuring . Perhaps they'll add actual pattern matching in a later release.
Actually the proposed java version is better than C#'s because it allows a form of exhaustiveness checking which C# doesn't even attempt to provide for.
However they had to add the `sealed` keyword too, which does not currently exist in java
Re: Pattern Matching for Java
#69IMO 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…
Maybe I'm misunderstanding your comment, but aren't case classes a fundamental piece of pattern matching? Or are you rather just suggesting the importance of which kinds of pattern matching are the most important?
match {
case v: java.util.Date =>
}
This still works without case class extractors and is useful. That's what I mean by matching and binding.
Extracting/destructuring in the match statement can sometimes be more trouble than it's worth. It's definitely brittle to changes in the case classes. Then there's the question of the (difficult to reason about?) cost of the abstraction.
Re: Pattern Matching for Java
#70I 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?