JEP: Derived Record Creation: Another Method

[David Alayachew]

Hello Nathan,

Wasn't the entire point of withers to simplify immutable transformation? As
in, let's make the simple case easy and obvious from a glance.

What you seem to be describing is the worst case scenario. You are
describing a transformation where most or all of the fields need to be
transformed in a very complex record in very complex ways. Is that not the
purpose of more general deconstruction and reconstruction functionality?

Let's pretend that your example given is super complex, and we would prefer
to transport the logic to a separate method.

In my mind, I would approach it like so.

if (oldLoc instanceof Point(int x, int y, int z))
{

    final Point nextLoc = complexTransformationLogic(x, y, z);

}
It's sort of like how switch and when clauses do not obviate the need for
an if statement with instanceof. It only smooths out the happy path and
provides you a few more benefits. If statements are still going to be more
flexible than switch. And in this case, I think the same can be said for if
statements vs withers.

And either way, if that is not enough, you can even do this.

final Point nextLoc = complexTransformationLogic(oldLoc);

This allows you to truly maximize the reuse. And aside from the overhead,
it seems to be semantically equivalent to what you proposed. And addressing
your nesting point, you can just nest the logic inside of the newly created
method, and then break that out into its own method too. You should still
have feature parity with what you described.

How do you feel about this?

Thank you for reaching out!
David Alayachew

On Fri, Jan 26, 2024 at 1:05 PM Nathan Reynolds <numeralnathan at gmail.com>
wrote:

> I am looking at JEP Derived Record Creation.
> https://openjdk.org/jeps/8321133  I see the following example.
>
> Point nextLoc = oldLoc with {
>     x *= 2;
>     y *= 2;
>     z *= 2;
> };
>
> If the body of the wither becomes more complex, then this will make reading the code difficult.  For example, there could be a deep nesting of wither.
>
> Lambdas can also be nested.  However, the best practice is to move multiline lambda bodies into a separate method and leave behind a single line that calls the method.  The ability to move the lambda bodies to another method allows for simplification of the code and improves readability.
>
> Can we change the design to allow withers to be moved to another method?  I ask without thinking through the ramifications.  If withers can't be moved to another method, how do we eliminate nesting and other complexities?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240126/60f2fbd1/attachment-0001.htm>