Use cases for pattern matching

[Brian Goetz]

Reconstruction expressions are built on matching pairs of constructors and deconstruction patterns.  We can put deconstruction patterns in interfaces (Map.Entry is a prime example), but not constructors.  At some point we may bring the notion of factory into the language more formally, in which case we could pair deconstruction patterns with either constructors or factories, and interfaces can have factories, so we might be able to get to something like what you’re asking about in the future, but currently that’s quite a few steps down the road.

Without some code in the interface for “how do I make a new one”, reconstruction expressions don’t really make sense.  It would not be reasonable to, say, look at the dynamic type of the receiver and try to guess how to make a new one based on that; a reconstruction expression should be given clear semantics based on the static types involved.  So for the time being, your example would be over the horizon of what reconstruction expressions could do — because it’s not even obvious what they _should_ do in this situation.

On Nov 22, 2023, at 7:28 AM, Sebastian Fischer <mail at sebfisch.de<mailto:mail at sebfisch.de>> wrote:

Hello.

Regarding the new features for pattern matching in JDK 21 I have some interesting use cases that highlight how they enable new ways to structure programs:

https://github.com/sebfisch/java21-demo/wiki/Pattern-Matching

Is this the right place to discuss them?

The first example uses a file search program to illustrate how algebraic data types are useful in stream pipelines, especially in handling errors as values when using a functional programming style. The second example uses tree-structured data and shows how core ideas from functional programming, especially related to data traversal, can be integrated into Java, leveraging streams and other functional programming patterns. Interestingly, the operations for data traversal can be reused instead of implementing specialized variants for each new tree structure.

I would be interested in what you expect about how the examples might change with future developments of Project Amber, especially regarding reconstruction expressions [1] and their relation to interfaces.

For example, the interface

    interface Named { String name(); }

can be implemented automatically by a record

    record Person(String name) implements Named {}

because the record component matches the signature of the interface.

It would be useful to be able to write

    named with { name = "New Name" }

for all implementations of `Named` (not only `Person`) and I wonder how `Named` could in the future be adjusted accordingly such that records still implement it automatically.

Best,
Sebastian

[1] https://mail.openjdk.org/pipermail/amber-spec-experts/2022-June/003461.html


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231127/96aaf415/attachment.htm>