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:
interface Function<T,U> {
U apply(T t);
<V> default Function<T, V> andThen(Function<U,V> g) { ... }
}
seems fine, but then when you extend it:
interface UnaryOperator<T> extends Function<T,T> {
}
you kind of lose, because you can't compose _unary operators_ using
Function::compose. And if you try to refine it:
interface UnaryOperator<T> extends Function<T,T> {
default UnaryOperator<T> andThen(UnaryOperator<T> g) { ... }
}
you end up overloading, not overriding the method, in a way that clients
cannot distinguish: `f.andThen(lambda)` will likely not be able to
distinguish between the overloads, because they have the same shape.
Ooops.
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".
Comparator seems less risky, because it is not designed to be extended
by domain objects, but instead functions more like a type class in
Haskell -- it is behavior _about_ a type, defined from the outside. And
Haskell would agree with you that this move is sensible; here's
Haskell's `Ord` (like Comparator), which extends `Eq` (providing equality.)
class (Eq a) => Ord a where
compare :: a -> a -> Ordering
(<), (<=), (>), (>=) :: a -> a -> Bool
max, min :: a -> a -> a
compare x y = if x == y then EQ
-- NB: must be '<=' not '<' to validate the
-- above claim about the minimal things that
-- can be defined for an instance of Ord:
else if x <= y then LT
else GT
x <= y = case compare x y of { GT -> False; _ -> True }
x >= y = y <= x
x > y = not (x <= y)
x < y = not (y <= x)
-- These two default methods use '<=' rather than 'compare'
-- because the latter is often more expensive
max x y = if x <= y then y else x
min x y = if x <= y then x else y
{-# MINIMAL compare | (<=) #-}
The `compare` method is like our Comparator method, just returning a
three-valued enum rather than an int. (Haskell has a cool feature here,
where you can define all the methods in terms of others, and then you
can override whichever ones make sense to break the cycles. The MINIMAL
annotation says "if you provide either compare or <=, you're good." I
wish we had this for interfaces with default methods.) It then proceeds
to derive `min` and `max` from `<=` (which might itself be derived from
`compare`.)
OK, "comparative languages" lesson over, back to your point. There are
two ways to get where you want: a static method that takes a comparator
and the operands (`Comparator.max(c, a, b)`), or a default method on
Comparator (`c.max(a, b)`). (You say "add simple static methods ... to
Comparator" but I think you mean to put the word `static` elsewhere in
that sentence.)
I am receptive to the idea of extending Comparator here, but would want
to think about it more to feel out potential mistakes like the `andThen`
one above. But your point is solid: a "comparator" is also a "maxxer"
and a "minner" (neither of those are words, and if they were, are
probably spelled wrong), and that is a natural place to locate such
behavior.
On 5/13/2025 10:12 AM, Tagir Valeev wrote:
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 extends Comparable<T>> T max(T a, T b) {
return a.compareTo(b) > 0 ? a : b;
}
Writing manually compareTo >= 0 looks too verbose, not very readable
and error-prone: one has to mention both objects twice, and it's
possible to mix > with <. I can surely add a method mentioned above to
a utility class in my project and use it everywhere. However, I feel
that it deserves a place in the standard library.
The alternatives we have now:
BinaryOperator.maxBy(Comparator.<T>naturalOrder()).apply(a, b);
This speaks clearly about the intent (we'd like to get the maximum and
we write 'maxBy') but very wordy.
Stream.of(a, b).max(Comparator.naturalOrder()).get();
Also clear and a little bit shorter, but has an unnecessary Optional
in-between (we know that we have at least one element, so the result
is always present) and we have to mention the comparator. Finally, it
might be much less efficient than expected.
Probably we can add simple static methods `max` and `min` either to
the `Comparator` interface, or to `java.util.Objects`? Such methods
would complement methods from the `Math` class for numbers. In
addition, having default methods `max` and `min` in the `Comparator`
interface would also be nice:
String bigger = String.CASE_INSENSITIVE_ORDER.max("Hello", "world");
What do you think? Can we proceed with such an enhancement?
With best regards,
Tagir Valeev
