为什么Optional不扩展Supplier
我使用了 供应商经常，我正在寻找新的 Guava 10 可选 现在。
与供应商相反，Optional 保证永远不会返回 null，但会抛出 IllegalStateException。此外，它是不可变的，因此一旦创建它就具有固定的已知值。与此相反，Supplier 可以用于创建通过调用 get() 触发的不同或惰性值（但不强制这样做）。
我关注了关于为什么可选不应该扩展供应商的讨论，我发现：
但我不明白为什么，因为供应商明确状态： 无保证此接口隐含了。
对我来说这很合适，但我似乎以前以与最初预期不同的方式雇用供应商。有人可以向我解释为什么选项不应该用作供应商吗？
是的：将Optional转换为Supplier非常容易（此外，您可以选择改编后的Supplier.get()是否返回Optional.get()或Optional.orNull()） 但您需要一些额外的转换，并且必须为每个对象创建新对象:-(
供应商的预期用途和我对其文档的理解之间似乎存在一些不匹配。Dieter
。
I used Supplier quite often and I'm looking at new Guava 10 Optional now.
In contrast to a Supplier an Optional guarantees never to return null but will throw an IllegalStateException instead. In addition it is immutable and thus it has a fixed known value once it is created. In contrast to that a Supplier may be used to create different or lazy values triggered by calling get() (but it is not imposed to do so).
I followed the discussion about why an Optional should not extend a Supplier and I found:
...it would not be a well-behaved Supplier
But I can't see why, as Supplier explicitly states:
No guarantees are implied by this interface.
For me it would fit, but it seems I used to employ Suppliers in a different way as it was originally intended. Can someone please explain to me why an Optional should NOT be used as a Supplier?
Yes: it is quite easy to convert an Optional into a Supplier (and in addition you may choose if the adapted Supplier.get() will return Optional.get() or Optional.orNull())
but you need some additional transformation and have to create new objects for each :-(
Seems there is some mismatch between the intended use of a Supplier and my understanding of its documentation.
Dieter.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
考虑一下这个例子
。您有一个包含一个方法的类型，该方法不带任何参数，但调用该方法会导致程序员错误！这真的有意义吗？
您只需要“当前”选项的供应商身份，然后，只需使用
Suppliers.ofInstance。Consider the case of
Think about this. You have a type containing one method, that takes no arguments, but for which it's a programmer error to ever invoke that method! Does that really make sense?
You'd only want Supplierness for "present" optionals, but then, just use
Suppliers.ofInstance.通常期望
Supplier能够返回对象（假设没有发生意外错误）。Optional是明确可能无法返回对象的东西。我认为“此接口不暗示任何保证”通常意味着不保证它如何检索对象，而不是该接口根本不需要暗示检索对象的能力。即使您认为
Supplier实例在每次调用get()时抛出异常是可以的，Guava 作者并不这么认为，而是选择只提供通常表现良好的供应商。A
Supplieris generally expected to be capable of returning objects (assuming no unexpected errors occur). AnOptionalis something that explicitly may not be capable of returning objects.I think "no guarantees are implied by this interface" generally means that there are no guarantees about how it retrieves an object, not that the interface need not imply the ability to retrieve an object at all. Even if you feel it is OK for a
Supplierinstance to throw an exception every time you callget()on it, the Guava authors do not feel that way and choose to only provide suppliers that can be expected to be generally well-behaved.