将 scala.math.Integral 作为隐式参数传递

发布于 2024-10-29 12:54:07 字数 651 浏览 2 评论 0原文

我已阅读关于 scala.math.Integral 但我不明白 Integral[T] 时会发生什么 传递为隐式参数。 (我想我总体上理解隐式参数的概念)。

让我们考虑这个函数

import scala.math._

def foo[T](t: T)(implicit integral: Integral[T]) { println(integral) }

现在我在 REPL 中调用 foo

scala> foo(0)  
scala.math.Numeric$IntIsIntegral$@581ea2
scala> foo(0L)
scala.math.Numeric$LongIsIntegral$@17fe89

integral 参数如何变成 scala.math.Numeric$IntIsIntegralscala .math.Numeric$LongIsIntegral

I have read the answer to my question about scala.math.Integral but I do not understand what happens when Integral[T] is passed as an implicit parameter. (I think I understand the implicit parameters concept in general).

Let's consider this function

import scala.math._

def foo[T](t: T)(implicit integral: Integral[T]) { println(integral) }

Now I call foo in REPL:

scala> foo(0)  
scala.math.Numeric$IntIsIntegral$@581ea2
scala> foo(0L)
scala.math.Numeric$LongIsIntegral$@17fe89

How does the integral argument become scala.math.Numeric$IntIsIntegral and scala.math.Numeric$LongIsIntegral ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

尛丟丟 2024-11-05 12:54:07

简而言之,Scala 在对象 Numeric 中找到 IntIsIntegralLongIsIntegral,该对象是类 Numeric 的伴生对象code>,它是 Integral 的超类。

继续阅读长答案。

隐式类型

Scala 中的隐式指的是可以“自动”传递的值,或者是自动进行的从一种类型到另一种类型的转换。

隐式转换

非常简单地谈论后一种类型,如果有人在类 C 的对象 o 上调用方法 m,并且该类执行以下操作:不支持方法 m,那么 Scala 将寻找从 C支持支持 m 的隐式转换。一个简单的例子是 String 上的 map 方法:

"abc".map(_.toInt)

String 不支持 map 方法,但是 >StringOps 确实如此,并且可以从 StringStringOps 进行隐式转换(请参阅 Predef< 上的implicit def AugmentString) /代码>)。

隐式参数

另一种隐式参数是隐式参数。这些参数像任何其他参数一样传递给方法调用,但编译器会尝试自动填充它们。如果做不到,就会抱怨。 可以显式传递这些参数,例如,这就是使用 breakOut 的方式(请参阅有关 breakOut 的问题,在您心情不好的一天来挑战)。

在这种情况下,必须声明对隐式的需要,例如 foo 方法声明:

def foo[T](t: T)(implicit integral: Integral[T]) {println(integral)}

View Bounds

有一种情况,隐式既是隐式转换又是隐式参数。例如:

def getIndex[T, CC](seq: CC, value: T)(implicit conv: CC => Seq[T]) = seq.indexOf(value)

getIndex("abc", 'a')

方法 getIndex 可以接收任何对象,只要存在从其类到 Seq[T] 的隐式转换。因此,我可以将 String 传递给 getIndex,并且它会起作用。

在幕后,编译将 seq.IndexOf(value) 更改为 conv(seq).indexOf(value)

这非常有用,以至于有一个语法糖可以编写它们。使用此语法糖,getIndex 可以这样定义:

def getIndex[T, CC <% Seq[T]](seq: CC, value: T) = seq.indexOf(value)

此语法糖被描述为视图边界,类似于上限(< code>CC <: Seq[Int])或下限T >: Null)。

请注意,视图边界从 2.11 开始已弃用,您应该避免使用它们。

上下文边界

隐式参数中的另一个常见模式是类型类模式。此模式可以为未声明公共接口的类提供公共接口。它既可以充当桥梁模式(实现关注点分离),也可以充当适配器模式。

您提到的 Integral 类是类型类模式的经典示例。 Scala 标准库的另一个例子是Ordering。有一个库大量使用了这种模式,称为 Scalaz。

这是它的使用示例:

def sum[T](list: List[T])(implicit integral: Integral[T]): T = {
    import integral._   // get the implicits in question into scope
    list.foldLeft(integral.zero)(_ + _)
}

它还有一个语法糖,称为上下文绑定,由于需要引用隐式内容,因此它的用处不大。该方法的直接转换如下所示:

def sum[T : Integral](list: List[T]): T = {
    val integral = implicitly[Integral[T]]
    import integral._   // get the implicits in question into scope
    list.foldLeft(integral.zero)(_ + _)
}

当您只需将上下文边界传递给使用它们的其他方法时,上下文边界会更有用。例如,Seq 上的sorted 方法需要隐式Ordering。要创建方法 reverseSort,可以这样写:

def reverseSort[T : Ordering](seq: Seq[T]) = seq.reverse.sorted

因为 Ordering[T] 已隐式传递给 reverseSort,因此它可以将其隐式传递给 <代码>排序。

隐式从何而来?

当编译器发现需要隐式参数时,无论是因为您正在调用对象的类中不存在的方法,还是因为您正在调用需要隐式参数的方法,它将搜索适合需要的隐式参数。

此搜索遵循某些规则,这些规则定义了哪些隐式可见,哪些不可见。下表显示了编译器将在何处搜索隐式内容,取自出色的 Josh Suereth 的关于隐式的演示,我衷心推荐给任何想要提高 Scala 知识的人。

  1. 首先查看当前范围
    1. 当前范围内定义的隐式
    2. 显式导入
    3. 通配符导入
    4. 其他文件中的相同范围
  2. 现在查看关联类型
    1. 某个类型的伴生对象
    2. 类型参数类型的伴生对象
    3. 嵌套类型的外部对象
    4. 其他尺寸

让我们举例说明。

当前范围中定义的隐式

implicit val n: Int = 5
def add(x: Int)(implicit y: Int) = x + y
add(5) // takes n from the current scope

显式导入

import scala.collection.JavaConversions.mapAsScalaMap
def env = System.getenv() // Java map
val term = env("TERM")    // implicit conversion from Java Map to Scala Map

通配符导入

def sum[T : Integral](list: List[T]): T = {
    val integral = implicitly[Integral[T]]
    import integral._   // get the implicits in question into scope
    list.foldLeft(integral.zero)(_ + _)
}

其他文件中的相同范围

这类似于第一个示例,但假设隐式定义与其用法位于不同的文件中。另请参阅如何使用包对象来引入隐式。

类型的伴生对象

这里有两个值得注意的伴生对象。首先,研究“源”类型的对象伴生体。例如,在对象 Option 内部有一个到 Iterable 的隐式转换,因此可以在 Option 上调用 Iterable 方法>,或将 Option 传递给需要 Iterable 的对象。例如:

for {
    x <- List(1, 2, 3)
    y <- Some('x')
} yield, (x, y)

该表达式由编译转换为

List(1, 2, 3).flatMap(x => Some('x').map(y => (x, y)))

然而,List.flatMap 需要一个 TraversableOnce,而 Option 则不是。然后,编译器查看 Option 的对象伴生对象并找到到 Iterable 的转换,即 TraversableOnce,从而使该表达式正确。

其次,预期类型的​​伴生对象:

List(1, 2, 3).sorted

sorted 方法采用隐式Ordering。在本例中,它会查找与 Ordering 类相伴的对象 Ordering 内部,并在那里找到隐式 Ordering[Int]

请注意,还会研究超类的伴生对象。例如:顺便说一句,

class A(val n: Int)
object A { 
    implicit def str(a: A) = "A: %d" format a.n
}
class B(val x: Int, y: Int) extends A(y)
val b = new B(5, 2)
val s: String = b  // s == "A: 2"

这就是 Scala 在您的问题中找到隐式 Numeric[Int]Numeric[Long] 的方式,因为它们是在 Numeric 中找到的,而不是整体

类型参数的伴随对象 类型

这是使类型类模式真正发挥作用所必需的。例如,考虑Ordering...它的伴生对象中带有一些隐式内容,但您无法向其中添加内容。那么如何为您自己的类创建一个自动找到的Ordering呢?

让我们从实现开始:

class A(val n: Int)
object A {
    implicit val ord = new Ordering[A] {
        def compare(x: A, y: A) = implicitly[Ordering[Int]].compare(x.n, y.n)
    }
}

因此,考虑调用时会发生什么

List(new A(5), new A(2)).sorted

正如我们所见,方法 sorted 需要一个 Ordering[A] (实际上,它需要一个 排序[B],其中B >:A)。 Ordering 中没有任何这样的东西,并且没有可供查看的“源”类型。显然,它是在 A 中找到的,它是 Ordering类型参数

这也是各种需要 CanBuildFrom 的集合方法的工作方式:在 CanBuildFrom 的类型参数的伴生对象中找到隐式。

嵌套类型的外部对象

我实际上还没有看到这样的例子。如果有人可以分享一个,我将不胜感激。原理很简单:

class A(val n: Int) {
  class B(val m: Int) { require(m < n) }
}
object A {
  implicit def bToString(b: A#B) = "B: %d" format b.m
}
val a = new A(5)
val b = new a.B(3)
val s: String = b  // s == "B: 3"

其他维度

我很确定这是一个笑话。我希望。 :-)

编辑

感兴趣的相关问题:

The short answer is that Scala finds IntIsIntegral and LongIsIntegral inside the object Numeric, which is the companion object of the class Numeric, which is a super class of Integral.

Read on for the long answer.

Types of Implicits

Implicits in Scala refers to either a value that can be passed "automatically", so to speak, or a conversion from one type to another that is made automatically.

Implicit Conversion

Speaking very briefly about the latter type, if one calls a method m on an object o of a class C, and that class does not support method m, then Scala will look for an implicit conversion from C to something that does support m. A simple example would be the method map on String:

"abc".map(_.toInt)

String does not support the method map, but StringOps does, and there's an implicit conversion from String to StringOps available (see implicit def augmentString on Predef).

Implicit Parameters

The other kind of implicit is the implicit parameter. These are passed to method calls like any other parameter, but the compiler tries to fill them in automatically. If it can't, it will complain. One can pass these parameters explicitly, which is how one uses breakOut, for example (see question about breakOut, on a day you are feeling up for a challenge).

In this case, one has to declare the need for an implicit, such as the foo method declaration:

def foo[T](t: T)(implicit integral: Integral[T]) {println(integral)}

View Bounds

There's one situation where an implicit is both an implicit conversion and an implicit parameter. For example:

def getIndex[T, CC](seq: CC, value: T)(implicit conv: CC => Seq[T]) = seq.indexOf(value)

getIndex("abc", 'a')

The method getIndex can receive any object, as long as there is an implicit conversion available from its class to Seq[T]. Because of that, I can pass a String to getIndex, and it will work.

Behind the scenes, the compile changes seq.IndexOf(value) to conv(seq).indexOf(value).

This is so useful that there is a syntactic sugar to write them. Using this syntactic sugar, getIndex can be defined like this:

def getIndex[T, CC <% Seq[T]](seq: CC, value: T) = seq.indexOf(value)

This syntactic sugar is described as a view bound, akin to an upper bound (CC <: Seq[Int]) or a lower bound (T >: Null).

Please be aware that view bounds are deprecated from 2.11, you should avoid them.

Context Bounds

Another common pattern in implicit parameters is the type class pattern. This pattern enables the provision of common interfaces to classes which did not declare them. It can both serve as a bridge pattern -- gaining separation of concerns -- and as an adapter pattern.

The Integral class you mentioned is a classic example of type class pattern. Another example on Scala's standard library is Ordering. There's a library that makes heavy use of this pattern, called Scalaz.

This is an example of its use:

def sum[T](list: List[T])(implicit integral: Integral[T]): T = {
    import integral._   // get the implicits in question into scope
    list.foldLeft(integral.zero)(_ + _)
}

There is also a syntactic sugar for it, called a context bound, which is made less useful by the need to refer to the implicit. A straight conversion of that method looks like this:

def sum[T : Integral](list: List[T]): T = {
    val integral = implicitly[Integral[T]]
    import integral._   // get the implicits in question into scope
    list.foldLeft(integral.zero)(_ + _)
}

Context bounds are more useful when you just need to pass them to other methods that use them. For example, the method sorted on Seq needs an implicit Ordering. To create a method reverseSort, one could write:

def reverseSort[T : Ordering](seq: Seq[T]) = seq.reverse.sorted

Because Ordering[T] was implicitly passed to reverseSort, it can then pass it implicitly to sorted.

Where do Implicits Come From?

When the compiler sees the need for an implicit, either because you are calling a method which does not exist on the object's class, or because you are calling a method that requires an implicit parameter, it will search for an implicit that will fit the need.

This search obey certain rules that define which implicits are visible and which are not. The following table showing where the compiler will search for implicits was taken from an excellent presentation about implicits by Josh Suereth, which I heartily recommend to anyone wanting to improve their Scala knowledge.

  1. First look in current scope
    1. Implicits defined in current scope
    2. Explicit imports
    3. wildcard imports
    4. Same scope in other files
  2. Now look at associated types in
    1. Companion objects of a type
    2. Companion objects of type parameters types
    3. Outer objects for nested types
    4. Other dimensions

Let's give examples for them.

Implicits Defined in Current Scope

implicit val n: Int = 5
def add(x: Int)(implicit y: Int) = x + y
add(5) // takes n from the current scope

Explicit Imports

import scala.collection.JavaConversions.mapAsScalaMap
def env = System.getenv() // Java map
val term = env("TERM")    // implicit conversion from Java Map to Scala Map

Wildcard Imports

def sum[T : Integral](list: List[T]): T = {
    val integral = implicitly[Integral[T]]
    import integral._   // get the implicits in question into scope
    list.foldLeft(integral.zero)(_ + _)
}

Same Scope in Other Files

This is like the first example, but assuming the implicit definition is in a different file than its usage. See also how package objects might be used in to bring in implicits.

Companion Objects of a Type

There are two object companions of note here. First, the object companion of the "source" type is looked into. For instance, inside the object Option there is an implicit conversion to Iterable, so one can call Iterable methods on Option, or pass Option to something expecting an Iterable. For example:

for {
    x <- List(1, 2, 3)
    y <- Some('x')
} yield, (x, y)

That expression is translated by the compile into

List(1, 2, 3).flatMap(x => Some('x').map(y => (x, y)))

However, List.flatMap expects a TraversableOnce, which Option is not. The compiler then looks inside Option's object companion and finds the conversion to Iterable, which is a TraversableOnce, making this expression correct.

Second, the companion object of the expected type:

List(1, 2, 3).sorted

The method sorted takes an implicit Ordering. In this case, it looks inside the object Ordering, companion to the class Ordering, and finds an implicit Ordering[Int] there.

Note that companion objects of super classes are also looked into. For example:

class A(val n: Int)
object A { 
    implicit def str(a: A) = "A: %d" format a.n
}
class B(val x: Int, y: Int) extends A(y)
val b = new B(5, 2)
val s: String = b  // s == "A: 2"

This is how Scala found the implicit Numeric[Int] and Numeric[Long] in your question, by the way, as they are found inside Numeric, not Integral.

Companion Objects of Type Parameters Types

This is required to make the type class pattern really work. Consider Ordering, for instance... it comes with some implicits in its companion object, but you can't add stuff to it. So how can you make an Ordering for your own class that is automatically found?

Let's start with the implementation:

class A(val n: Int)
object A {
    implicit val ord = new Ordering[A] {
        def compare(x: A, y: A) = implicitly[Ordering[Int]].compare(x.n, y.n)
    }
}

So, consider what happens when you call

List(new A(5), new A(2)).sorted

As we saw, the method sorted expects an Ordering[A] (actually, it expects an Ordering[B], where B >: A). There isn't any such thing inside Ordering, and there is no "source" type on which to look. Obviously, it is finding it inside A, which is a type parameter of Ordering.

This is also how various collection methods expecting CanBuildFrom work: the implicits are found inside companion objects to the type parameters of CanBuildFrom.

Outer Objects for Nested Types

I haven't actually seen examples of this. I'd be grateful if someone could share one. The principle is simple:

class A(val n: Int) {
  class B(val m: Int) { require(m < n) }
}
object A {
  implicit def bToString(b: A#B) = "B: %d" format b.m
}
val a = new A(5)
val b = new a.B(3)
val s: String = b  // s == "B: 3"

Other Dimensions

I'm pretty sure this was a joke. I hope. :-)

EDIT

Related questions of interest:

旧人哭 2024-11-05 12:54:07

该参数是隐式的,这意味着 Scala 编译器将查找是否可以在某个地方找到可以自动填充该参数的隐式对象。

当您传入 Int 时,它将查找一个 Integral[Int] 隐式对象,并在 scala.math.Numeric< 中找到它/代码>。您可以查看 scala.math.Numeric 的源代码,您会发现:

object Numeric {
  // ...

  trait IntIsIntegral extends Integral[Int] {
    // ...
  }

  // This is the implicit object that the compiler finds
  implicit object IntIsIntegral extends IntIsIntegral with Ordering.IntOrdering
}

同样,Long 有一个不同的隐式对象,其工作方式相同。

The parameter is implicit, which means that the Scala compiler will look if it can find an implicit object somewhere that it can automatically fill in for the parameter.

When you pass in an Int, it's going to look for an implicit object that is an Integral[Int] and it finds it in scala.math.Numeric. You can look at the source code of scala.math.Numeric, where you will find this:

object Numeric {
  // ...

  trait IntIsIntegral extends Integral[Int] {
    // ...
  }

  // This is the implicit object that the compiler finds
  implicit object IntIsIntegral extends IntIsIntegral with Ordering.IntOrdering
}

Likewise, there is a different implicit object for Long that works the same way.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文