Collections.max(List.of(a, b))?
On Tue, May 13, 2025 at 7:12 PM Tagir Valeev wrote:
> The alternatives we have now:
> BinaryOperator.maxBy(Comparator.naturalOrder()).apply(a, b);
> This speaks clearly about the intent (we'd like to get the maximum and we
> write 'maxBy') but very wordy.
>
> Stre
Hi,
I don't know if anyone still uses this, but some ideas are worth
considering:
https://github.com/google/guava/blob/master/guava/src/com/google/common/collect/Ordering.java
This is a Comparator implementation that also defines min and max. As
generic methods.
So if I have:
Comparator
Hello!
On Tue, May 13, 2025 at 5:53 PM Brian Goetz wrote:
> Let's separate these. I think the first two have a good claim to be in
> Comparator; I think the latter two probably live better in Comparable,
> which feels like a separate conversation (and maybe less important?)
> (And also, there's
Well, probably I formulated it not so clearly. I'd like to have the
following additions:
public interface Comparator {
...
default T max(T a, T b) {
return compare(a, b) > 0 ? a : b;
}
default T min(T a, T b) {
return compare(a, b) > 0 ? b : a;
}
stati
Hello, Brian!
On Tue, May 13, 2025 at 4:30 PM Brian Goetz wrote:
> So with that as background, I am very cautious to consider adding methods to
> Comparable, because it is a highly abstract type that was designed for
> extension, and the risk of the above kind of clash seems "not low".
Sure, e
> From: "Brian Goetz"
> To: "Tagir Valeev" , "core-libs-dev"
>
> Sent: Tuesday, May 13, 2025 4:30:33 PM
> Subject: Re: Finding max or min of exactly two objects
> When we did Lambda, we made a few mistakes in the category of adding default
&g
Hello!
Several times already when writing Java programs, I stumbled with a simple
task: given two objects with natural order, find the maximal of them. The
algorithm I need could be formulated like this:
> T max(T a, T b) {
return a.compareTo(b) > 0 ? a : b;
}
Writing manually co
When we did Lambda, we made a few mistakes in the category of adding
default methods to some "highly abstract" types, such as
Function::andThen. You were there; these were well-intentioned, but we
neglected to think sufficiently about the consequences for subclasses.
For example:
interf
