JEP: Derived Record Creation: Another Method

[David Alayachew]

💖

David reacted via Gmail
<https://www.google.com/gmail/about/?utm_source=gmail-in-product&utm_medium=et&utm_campaign=emojireactionemail#app>

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

> 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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/vnd.google.email-reaction+json
Size: 37 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240126/dd0e85cf/attachment-0001.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240126/dd0e85cf/attachment-0001.htm>