Java 8 是否缺少 OptionalBoolean?
作为可选的原始版本a>*，Java 1.8 提供 OptionalInt、OptionalLong 和 OptionalDouble.
As a primitive version of Optional*, Java 1.8 provides OptionalInt, OptionalLong and OptionalDouble.
但我找不到等效的 OptionalBoolean 类.
But I cannot find the equivalent OptionalBoolean class.
是否有任何技术原因反对使用 OptionalBoolean?
Are there any technical reasons against having an OptionalBoolean?
*可选可能有也可能没有值，用作null的替代.
*
An Optional may or may not have the presence of a value, is used as an alternative to null.
推荐答案
这句话解释了拥有原始流背后的注意事项.我假设同样适用于原始 Optionals.简而言之，出于性能原因，创建了原始流(可能还有 Optionals).他们没有为所有 8 种原始类型创建它们以减少代码重复和接口污染.
This quote explains the considerations behind having primitive streams. I'm assuming the same applied to primitive Optionals. In short, primitive streams (and probably Optionals as well) were created for performance reasons. They didn't create them for all 8 primitive types to reduce code duplication and interface pollution.
在 lambda 邮件中引用 Brian Goetz 的话列表:
更笼统地说:专业化背后的哲学原始流(例如，IntStream)充满了令人讨厌的权衡.一方面，它有很多丑陋的代码重复，界面污染等另一方面，任何类型的盒装操作算术糟透了，没有减少整数的故事会很糟糕.所以我们正处于一个艰难的角落，我们正在努力不让情况变得更糟.
More generally: the philosophy behind having specialized primitive streams (e.g., IntStream) is fraught with nasty tradeoffs. On the one hand, it's lots of ugly code duplication, interface pollution, etc. On the other hand, any kind of arithmetic on boxed ops sucks, and having no story for reducing over ints would be terrible. So we're in a tough corner, and we're trying to not make it worse.
不让事情变得更糟的诀窍 #1 是:我们没有做所有八个原始类型.我们正在做 int、long 和 double；所有其他人可以通过这些来模拟.可以说我们也可以摆脱 int ，但是我们认为大多数 Java 开发人员还没有为此做好准备.是的，那里将调用 Character，答案是将其放入 int 中".(预计每个专业化的 JRE 足迹约为 100K.)
Trick #1 for not making it worse is: we're not doing all eight primitive types. We're doing int, long, and double; all the others could be simulated by these. Arguably we could get rid of int too, but we don't think most Java developers are ready for that. Yes, there will be calls for Character, and the answer is "stick it in an int." (Each specialization is projected to ~100K to the JRE footprint.)
技巧 #2 是:我们使用原始流来公开在原始域中最好完成的事情(排序、归约)，但不是试图复制您在盒装域中可以做的所有事情.为了例如，正如 Aleksey 指出的那样，没有 IntStream.into().(如果有是，下一个问题将是IntCollection 在哪里?数组列表?IntConcurrentSkipListMap?) 意图是多流可能以参考流开始并以原始流结束，但是反之亦然.没关系，这减少了转换次数需要(例如，int -> T 的映射没有重载，没有特殊化int -> T 等的函数)
Trick #2 is: we're using primitive streams to expose things that are best done in the primitive domain (sorting, reduction) but not trying to duplicate everything you can do in the boxed domain. For example, there's no IntStream.into(), as Aleksey points out. (If there were, the next question(s) would be "Where is IntCollection? IntArrayList? IntConcurrentSkipListMap?) The intention is many streams may start as reference streams and end up as primitive streams, but not vice versa. That's OK, and that reduces the number of conversions needed (e.g., no overload of map for int -> T, no specialization of Function for int -> T, etc.)
我应该提到，我在 这个问题.
相关文章