Use cases for pattern matching

[Sebastian Fischer]

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

Indeed. I saw the section on interfaces in the document [1] linked in your
post mentioned earlier. But it seems like the presented factory and
deconstructor come with implementations inside the interface, whereas I
think my use case would need something like "has a constructor and a
corresponding deconstructor that include the names ..." to be expressible
in an interface.

Different implementations of such an interface could implement constructors
and deconstructors in different ways and potentially with more parameters
as required by the interface. For example in addition to the shown Person
record implementing the Named interface we could have:

    record Ingredient(String name, int grams) implements Named

and for my original use case (generic data traversal) it would be useful if
I could somehow define the interface Named in such a way that both Person
and Ingredient implement it automatically (because both records have a
canonical constructor and corresponding deconstructor that include the
variable "name".)

Instead of capturing the meaning of reconstruction expressions by using
constructors (or factories) and deconstructors, a more specialized way to
define such interfaces could be as follows:

    interface Named {
        __components(String name, /* potentially more like in record
declarations */);
    }

Such an interface declaration could mean that implementations allow
reconstruction expressions with assignments to the variable "name" and a
corresponding getter.

I realize that support for defining such interfaces is far ahead and may
never be available. I like to point out that such functionality fits
records (maybe other classes with corresponding constructors and
deconstructors too) and would be useful for generic data traversal (and
potentially other use cases.) To complete the example given here, I'd like
to be able to define:

    static <N extends Named> N withNewName(N named, String newName) {
        return named with { name = newName };
    }

and be able to use it for both Person and Ingredient. The hypothetical
interface declaration above seems to cover this use case. I think I have a
clear understanding of what it would mean but may be missing aspects I'm
currently unaware of.

[1]
https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md

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> 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/20231128/55a2b0e7/attachment.htm>