Why there is no BooleanConsumer in Java 8?

后端 未结 3 1111
囚心锁ツ
囚心锁ツ 2021-02-05 00:04

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

相关标签:
3条回答
  • 2021-02-05 00:28

    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.

    0 讨论(0)
  • 2021-02-05 00:36

    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 Runnables representing "do something" and "do something else". In many cases, you would only need one of the Runnables 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 BooleanSuppliers 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.

    0 讨论(0)
  • 2021-02-05 00:37

    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>

    0 讨论(0)
提交回复
热议问题