I\'m afraid that this is somewhat a silly question.
Is there anybody can tell me why there is no BooleanConsumer
opposite to BooleanSupplier?
Is the
You can write your own BooleanConsumer, but in order to make it really useful, you would need to write your own BooleanStream, too. There is an IntStream, LongStream, and DoubleStream, but no "BooleanStream" (or "ShortStream", "FloatStream" etc). It seems that these primitives were judged not to be important enough.
You can always use Boolean objects instead of boolean primitives, and a Boolean Consumer to consume the values. Example code:
public class Main {
public static void main(String[] args) {
Consumer<Boolean> myConsumer = b -> System.out.println("b = " + b);
Stream.of("aa", "bb", "cc")
.map(Main::myBooleanFunction)
.forEach(myConsumer);
}
static boolean myBooleanFunction(String s) {
return s.startsWith("b");
}
}
myBooleanFunction returns a boolean, but using it in a map creates a stream of Booleans (because we are in the generic, non-primitive Stream. Again, we have mapToInt, mapToLong, mapToDouble to create an IntStream etc, but no mapToBoolean).
If you don't need stream support, you can still write and use a "BooleanConsumer" in order to provide a type for some behavior, put I would prefer to see a functional interface with a more specific and descriptive name.
As other answers indicate there is no great reason to avoid Consumer<Boolean>
, but then there's no great reason to avoid Supplier<Boolean>
either, so a different explanation is required for this.
A similar question is why can't you switch on a boolean
value. The answer is that there's no need because you could always use if
or if else
.
A BooleanConsumer
would really be nothing more than an if else
construct because the accept()
method for a BooleanConsumer
could always be written in this form:
if (v) {
// Do something
} else {
// Do something else
}
If you needed to pass such code around as data, you could just pass a pair of Runnable
s representing "do something" and "do something else". In many cases, you would only need one of the Runnable
s because one of the two blocks above would be empty.
In the same way, there is no need for a BooleanPredicate
because it would be nothing more than a pair of BooleanSupplier
s and there is no need for a a BooleanFunction<R>
because it would be nothing more than a pair of Supplier<R>
s.
In contrast to this, it is not possible to break a BooleanSupplier
into two simpler objects.
IntConsumer
and LongConsumer
are needed to avoid the overhead autoboxing every value. It is much more efficent to be working on raw primitives.
However, for Boolean and Byte every possible object is cached so there is little reason to avoid using Consumer<Boolean>
or Consumer<Byte>