Other ways to use destructuring

[David Alayachew]

Hello P Holder,

Thank you for posting!

I'm not part of the Amber Dev Team, just a commenter, but I have a few
thoughts.

> In thinking about record destructuring it occurs to
> me it could be used in more places than currently
> proposed.

I'll start off by making the assumption that all of these examples you then
provided are things that are currently not possible in Java 20. I have been
playing with destructuring a lot lately, but I might have missed a few
things. So, putting this disclaimer up front.

Working on that assumption, I see a lot of value in what you are
describing, but I fear that there is a significant cost that is not being
acknowledged in your proposal. I'll go through each one.

> One example would be in a function call:
>
> record HumanName(firstName: String, middleName: String, lastName: String)
{}
>
> HumanName humanName = new HumanName(“Alice”, “Bateman”, “Chandler”);
>
> String getFormattedName(humanName: HumanName(firstName, _, lastName))
> {
>
>    return lastName + “, “ + firstName;
>
> }
>
> final String fmtName = getFormattedName(humanName);

You have brought an implementation detail of the class into the method
signature of getFormattedName.

The purpose of a method signature is to define a method's name, its
parameters, and its return type. To add things like this destructuring to
the signature adds a lot of complexity. Complexity can be acceptable, but
there needs to be a good reason for it being there.

I can definitely see some good reasons. Looking at the above signature, it
is clear that a null HumanName will end up in some failure state for this
method. Exception probably. It's also clear that middleName isn't required,
so it allows me to focus my validation efforts on the fields required. This
proposal definitely provides value.

However, I don't think that the value outweighs the costs here.

Most of the value I described could be achieved by both looking at the
contents of the method you are calling and reading its preconditions. Yes,
sometimes, the method we are looking at has no documentation and has
already been compiled with no source code available. But even then, this
feels like a poor solution to deal with that problem. After all, not all
preconditions can be (easily or reasonably) described through
deconstruction patterns. And even if they could be, you still end up with a
constraint that only exists at run time. None of those preconditions exist
at compile time.

But maybe I am not seeing it. Could you go into more details about the
benefits that adding deconstruction patterns in the method header provides
us?

> another could be in a for loop
>
> final Set<HumanName> humans = new HashSet<>();
>
> humans.add(humanName);
>
> for (final humanName: HumanName(firstName, _, lastName): humans)
>
> {
>
>    processFirstName(firstName);
>
>    processLastName(lastName);
>
>    ...
>
> }

This functionality is actually already being considered. In fact, it was
briefly previewed before they pulled it back. It's written in JEP 440 that
they took it out from the record patterns JEP, so that it can be delivered
separately later on. So, it is on its way, just not here now. Here is a
link to the JEP 440 itself -- https://openjdk.org/jeps/440

I would also click around and view the other JEP's involving record
patterns -- https://openjdk.org/jeps/0

> or indeed in any body
>
> with humanName as HumanName(firstName, _, lastName)
>
> {
>
>    processFirstName(firstName);
>
>    processLastName(lastName);
>
>    ...
>
> }

This too is being considered. Here is a youtube video that goes into what a
possible implementation of this might look like --
https://youtu.be/L6BS2F0dWXQ?t=4485

Thank you for reaching out!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230403/8cfe412f/attachment-0001.htm>