我正在阅读这篇博客文章，声称Futures它们不是“有效的”，因为它们只是副作用计算的包装。例如，它们包含RPC调用，HTTP请求等。是否正确？
该博客文章给出了以下示例：
def twoUsersFeed(a: UserHandle, b: UserHandle)
(implicit ec: ExecutionContext): Future[Html] =
for {
feedA <- usersFeed(a)
feedB <- usersFeed(b)
} yield feedA ++ feedB
you lose the desired property: consistent results (the referential transparency). Also you lose the property of making as few requests as possible. It is difficult to use multi-valued requests and have composable code.
恐怕我不明白。您能解释一下consistent result在这种情况下我们怎么输了吗？
该博客文章未能在Future其自身和常用方式IMO之间做出适当区分。Future如果您只曾写过Future称为完全函数的，则可以使用编写纯函数代码；这样的代码在每个遥远的合理意义上都是参照透明的，并且是“功能性的”。
正确的是Future，如果您将s与副作用的方法结合使用，则可以使您有限地控制副作用。如果创建Future包装webClient.get，则创建该包装Future将发送HTTP调用。但这不是事实Future，这是事实webClient.get！
在这篇博客文章中有一点道理。通过例如Free monad将表达与执行完全区分开来，可以提高代码效率和测试性。例如，您可以创建一种“查询语言”，在其中无需进行实际操作即可表达“获取A和B的所有共同朋友的个人资料照片”之类的操作。这使您更容易测试您的逻辑是否正确（因为非常容易进行例如可以“运行”相同查询的测试实现，甚至可以直接检查“查询对象”），而且，正如我认为的博客文章一样试图建议，这意味着您可以例如组合多个请求以获取相同的配置文件。（这甚至不是纯粹的功能编程问题-一些面向对象的书籍都具有“命令模式”的概念for/yield语法可以更轻松地以这种方式工作）。假设您所拥有的只是一种fetchProfile在运行时立即触发HTTP请求的方法，那么如果您的代码逻辑两次请求相同的配置文件，则无法避免两次获取相同的配置文件。
但是，这Future本质上并不是真正的问题，而且IMO的此博客文章比帮助更令人困惑。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句