On Mon, 20 Jan 2025 11:43:13 GMT, Aviad Zer <d...@openjdk.org> wrote:
>> This change extends the Math.min function to support multiple parameters, >> improving its usability and code readability. >> >> Previously, finding the minimum value among multiple variables required >> using nested Math.min calls or converting the variables into an array and >> iterating through it. This enhancement provides a more intuitive and >> straightforward approach to achieve the same result. >> >> Benefits: >> >> Simplifies code by eliminating the need for nested Math.min calls. >> Enhances readability, especially when comparing multiple values. >> Offers consistency with existing Math.min usage patterns. > > Aviad Zer has updated the pull request incrementally with one additional > commit since the last revision: > > Update Math.java by adding extended max function Can you please keep the PR? I'm still working on it בתאריך יום ו׳, 7 בפבר׳ 2025, 15:16, מאת Per-Ake Minborg < ***@***.***>: > Thanks for socializing your idea @aviad1486 <https://github.com/aviad1486> > ! > > I think we should *not* integrate this PR and there are many reasons for > that including, but not limited to: > > - There are easy ways to provide this kind of functionality outside > the JDK. > - We are not sure there is a need for this in the community. > - Adding these overloads means we commit to supporting them in > perpetuity. > - There are works ongoing to intensify Math::min and Math::max. This > means we'd have to do the same here. > - There are replacements for many similar constructs (e.g. using a > reduction of streams). > - The reviewing capacity is limited and currently, we are focusing on > major additions to the Java platforms (e.g. Valhalla). > - It is not clear which other methods in Math (and MathExact) should > be expanded in a similar way. > - It is not clear what performance, escape analysis, and inline > factors this would impact. > > Languages such as Haskel support "infix" operators meaning you could write > something like a 'min' b 'min' c. If such a feature would be available in > Java in the distant future, then the use of the proposed methods would be > reduced but we would still have to maintain them forever. > > So, I strongly suggest that we should close this PR without integrating > it. Thanks again @aviad1486 <https://github.com/aviad1486> for your > effort. > > — > Reply to this email directly, view it on GitHub > <https://github.com/openjdk/jdk/pull/23138#issuecomment-2642878666>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/BEHBFNK742B4HJSYSAB4YQL2OSW2ZAVCNFSM6AAAAABVHL4VJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBSHA3TQNRWGY> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > ------------- PR Comment: https://git.openjdk.org/jdk/pull/23138#issuecomment-2643132031
