<div dir="ltr">That sounds great! I am glad there is an easy clean solution.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 26, 2024 at 12:19 PM David Alayachew <<a href="mailto:davidalayachew@gmail.com">davidalayachew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hello Nathan,</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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?</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Let's pretend that your example given is super complex, and we would prefer to transport the logic to a separate method.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">In my mind, I would approach it like so.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">if (oldLoc instanceof Point(int x, int y, int z))</div><div class="gmail_default" style="font-family:monospace">{</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace"> final Point nextLoc = complexTransformationLogic(x, y, z);<br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">}</div><div><div style="font-family:monospace" class="gmail_default"></div></div><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">And either way, if that is not enough, you can even do this.<div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">final Point nextLoc = complexTransformationLogic(oldLoc);<br></div></div><div><br></div><div><div style="font-family:monospace" class="gmail_default">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.<br></div></div><div></div>
</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">How do you feel about this?<br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thank you for reaching out!</div><div class="gmail_default" style="font-family:monospace">David Alayachew<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 26, 2024 at 1:05 PM Nathan Reynolds <<a href="mailto:numeralnathan@gmail.com" target="_blank">numeralnathan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I am looking at JEP Derived Record Creation. <a href="https://openjdk.org/jeps/8321133" target="_blank">https://openjdk.org/jeps/8321133</a> I see the following example.<br></div><div></div><div>
<pre><code>Point nextLoc = oldLoc with {
x *= 2;
y *= 2;
z *= 2;
};<br><span style="font-family:arial,sans-serif"><br></span></code><span style="font-family:arial,sans-serif">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.<br></span></pre><pre><span style="font-family:arial,sans-serif">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.<br><br></span></pre><pre><span style="font-family:arial,sans-serif">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?</span>
</pre>
</div></div>
</blockquote></div>
</blockquote></div>