关于扩展Scala方法签名

Question

几个月后，我对Scala几乎完全陌生了。我注意到一些狂野的签名。我已经使用contrapositive/copositive/extensions/invariance，和大多数基础知识完成了泛型工作。但是，我仍然觉得有些方法签名有点混乱。虽然我找到了一些例子，并且知道签名会产生什么结果，但对于某些功能，我仍然有些不知所措。在谷歌上搜索我的问题，让我没有答案。我确实有一个普遍的想法，那就是人们喜欢把基本的CS 1的东西打死。我甚至试图在scala网站上找到答案。也许我的措辞是错误的，比如“扩展方法签名”和“scala签名中的定义函数使用”。有人能解释一下这个签名吗？

futureUsing[I <: Closeable, R](resource: I)(f: I => Future[R])(implicit ec: ExecutionContext):Future[R]

我的猜测是，在初始化泛型和参数声明后，定义了I类型的参数，最后一部分是函数的任何特定对象，或者必须在隐式范围内查找的对象(它们随后是否被销毁？)。有人可以布局一个扩展的方法签名，使我知道我正在使用的代码吗？最后两部分是否有特定的顺序？

Note

经过一系列的搜索，我找到了一些有效的答案，我可以把它们放在一起：

-Scala - Currying and default arguments

-why in Scala a function type needs to be passed in separate group of arguments into a function

没有一种集合排序，只有最后一种才能得出结果。位置是关于依赖的，它从左到右流动，就像上面的答案中有人在列表中所指出的那样。为什么我不能先推理，然后再依赖它们，这是很奇怪的，因为没有可用的东西会导致错误，而事情很可能取决于给定的隐式。

不过，我还是有点糊涂。当指定f: i => FutureR并需要提供最后一个参数时，让我们假装它是隐式的，我是否需要做更类似的事情：

futureUsing(resourceOfI)({stuff => doStuff(stuff)})(myImplicit)

这是对的吗？

我可以这样做吗？

futureUsing(resourceOfI)(myImplicit)({stuff => doStuff(stuff)})

为什么？我真的在试图找出根本的原因，而不仅仅是二进制的是或否。

Final Note

我刚找到答案。该顺序似乎无法更改。如果我错了，请纠正我。

Scala: Preference among overloaded methods with implicits, currying and defaults

Answer 1

有人能解释一下这个签名吗？

futureUsing[I <: Closeable, R]

futureUsing使用两种不同的类型(两个类型参数)。我们不知道它们的确切类型，但是我们将调用一个I (输入)，它是一个(或派生自) Closable，而另一个R (结果)。

(resourse: I)

futureUsing的第一个急迫论点是I类型。我们叫它resourse。

(f: I => Future[R])

第二个curried参数，f，是一个函数，它接受I类型的参数，并返回一个Future，该Future将(最终)包含某种类型的R。

(implicit ec: ExecutionContext)

第三个急迫的论点，ec，是ExecutionContext类型。这个参数是隐式的，这意味着如果在调用futureUsing时没有提供它，编译器将在作用域中查找已声明为implicit的ExecutionContext，并将其作为第三个参数。

:Future[R]

futureUsing返回一个Future，其中包含R类型的结果。

这个有什么特别的定单吗？

隐式参数必须是最后(最右边的)参数。除此之外，no、resourse和f都可以按这两种顺序声明。当然，在调用时，参数的顺序必须与定义中声明的顺序相匹配。

我需要..。请求牵扯进来？

在ExecutionContext的情况下，让编译器使用import scala.concurrent.ExecutionContext提供的内容。只有在很少的情况下，你才需要一些不同的东西。

...how会用第二个急迫的论点.

在futureUsing的正文中，我希望看到f(resourse)。f采用I类型的参数。resourse是I型的。f返回Future[R]，futureUsing也返回，因此行f(resourse)可能是futureUsing正文中的最后一条语句。