JEP: Derived Record Creation: Another Method

[Nathan Reynolds]

That sounds great!  I am glad there is an easy clean solution.

On Fri, Jan 26, 2024 at 12:19 PM David Alayachew <davidalayachew at gmail.com>
wrote:

> 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/1ad37d0e/attachment.htm>