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

21–30 of 152 posts

Re: Pattern Matching for Java

#22

Post by edejong »

flavor8 wrote: post #4

Any substantial differences from Scala's implementation? From what I remember of Odersky's book it seems very similar if not identical. (Which is fine - I'm all for Java incorporating the best parts of Scala.)

For me the best parts would include:

- Type inference

- Everything is an object (no more primitives)

- no obligatory ';' as a statement separator

- Type-classes

- Scoped import statements

At which point we're actually recreating Scala and we might as well switch :)

Re: Pattern Matching for Java

#23

Post by zastrowm »

Reading this reminded me of all the discussions that took/are taking place for pattern matching in C#[0]; reading this I had the same reactions that I did for C#: cool stuff. It's also nice to see the languages reach parity in features; I only hope the two language committees pay attention to the research/feedback that the other receives.

[0]: https://github.com/dotnet/roslyn/issues/10153

Re: Pattern Matching for Java

#24

Post by holtalanm »

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.

Re: Pattern Matching for Java

#26

Post by zastrowm »

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

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

Re: Pattern Matching for Java

#28

Post by jdmichal »

stickfigure wrote: post #18

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.

I had the same comment on C#'s implementation:

https://news.ycombinator.com/item?id=12971841#12972691

In C#, the "wanting the supertype" answer makes some sense with explicit interface implementations [0]. Java doesn't have that, and AFAIK there's no way to declare something that's visible on a supertype but not a subtype.

[0] I think it's a bad reason. But the possibility does at least exist.

Re: Pattern Matching for Java

#29

Post by rdnetto »

Would 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 sequence of predicate-function pairs and applies them appropriately. This looks like so:

    new PatternMatchingHelper()
    .append(Foo.class, foo -> doSomething(foo.x))
    .append(Bar.class, bar -> doSomethingElse(bar.y, bar.z))
    .otherwise(x -> fallbackValue())
    .apply(objectOfUnknownType);
The main disadvantage here is that it doesn't work well with generics, because the class objects have raw types.

You could probably extend the second approach to get something close to the arbitrary predicates that pattern matching would provide, but the syntax wouldn't be nearly a clean as having it in the language.

Re: Pattern Matching for Java

#30

Post by barrkel »

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

Multiple dispatch is sometimes more elegant, provided you can divorce the method being dispatched to from the argument classes. If you need to do it with a visitor pattern and multiple callbacks, it's much worse. If you need completeness checking, it's worse. If you've got a simple concise algorithm best expressed in a loop, it's worse. If you've got a nested structure that you want to partially destructure, it's worse.

As you've found, overloading is statically typed multiple dispatch; discovering the right overloaded method at runtime is functionally equivalent to multiple dispatch if your overload resolution rules prefer more specific derived types (rather than simply giving up with ambiguity).

Post reply on HN