Scala(或Java)中泛型函数的专业化

K J*_*K J 28 java generics scala specialized-annotation

是否可以在Scala中专门化泛型函数(或类)?例如,我想编写一个将数据写入ByteBuffer的泛型函数:

def writeData[T](buffer: ByteBuffer, data: T) = buffer.put(data)
Run Code Online (Sandbox Code Playgroud)

但由于put方法只需要一个字节并将其放入缓冲区,我需要将它专门用于Ints和Longs,如下所示:

def writeData[Int](buffer: ByteBuffer, data: Int) = buffer.putInt(data)
def writeData[Long](buffer: ByteBuffer, data: Long) = buffer.putLong(data)
Run Code Online (Sandbox Code Playgroud)

它不会编译.当然,我可以分别编写3个不同的函数writeByte,writeInt和writeLong,但是假设有一个数组的另一个函数:

def writeArray[T](buffer: ByteBuffer, array: Array[T]) {
  for (elem <- array) writeData(buffer, elem)
}
Run Code Online (Sandbox Code Playgroud)

如果没有专门的writeData函数,这将无法工作:我将不得不部署另一组函数writeByteArray,writeIntArray,writeLongArray.每当我需要使用类型相关的写函数时,必须以这种方式处理这种情况并不酷.我做了一些研究,一个可能的解决方法是测试参数的类型:

def writeArray[T](buffer: ByteBuffer, array: Array[T]) {
  if (array.isInstanceOf[Array[Byte]])
    for (elem <- array) writeByte(buffer, elem)
  else if (array.isInstanceOf[Array[Int]])
    for (elem <- array) writeInt(buffer, elem)
  ...
}
Run Code Online (Sandbox Code Playgroud)

这可能有效,但效率较低,因为类型检查是在运行时完成的,与专用函数版本不同.

所以我的问题是,在Scala或Java中解决此类问题的最理想和首选方法是什么?我提前感谢您的帮助!

Rex*_*err 19

如果你能同时拥有一个紧凑而有效的解决方案,那不是很好吗?事实证明,鉴于Scala的@specialized功能,你可以.首先警告:该功能有些错误,如果你试图将它用于太复杂的东西,可能会破坏.但对于这种情况,它几乎是完美的.

@specialized注释为每个基本类型创建单独的类和/或方法,然后调用,而不是通用版本每当编译器知道确切的基本类型是什么.唯一的缺点是它完全自动完成所有这些 - 你无法填写自己的方法.这是一种耻辱,但你可以使用类型类来克服这个问题.

我们来看一些代码:

import java.nio.ByteBuffer
trait BufferWriter[@specialized(Byte,Int) A]{
  def write(b: ByteBuffer, a: A): Unit
}
class ByteWriter extends BufferWriter[Byte] {
  def write(b: ByteBuffer, a: Byte) { b.put(a) }
}
class IntWriter extends BufferWriter[Int] {
  def write(b: ByteBuffer, a: Int) { b.putInt(a) }
}
object BufferWriters {
  implicit val byteWriter = new ByteWriter
  implicit val intWriter = new IntWriter
}
Run Code Online (Sandbox Code Playgroud)

这给了我们一个BufferWriter特点是通用的,但我们覆盖每一个我们想要的特定的基本类型(在这种情况下Byte,并Int用合适的实现).专业化足够聪明,可以将此显式版本与通常用于专业化的隐藏版本链接起来.所以你有自定义代码,但是你如何使用它?这是隐含的val进来的地方(我已经这样做了速度和清晰度):

import BufferWriters._
def write[@specialized(Byte,Int) A: BufferWriter](b: ByteBuffer, ar: Array[A]) {
  val writer = implicitly[BufferWriter[A]]
  var i = 0
  while (i < ar.length) {
    writer.write(b, ar(i))
    i += 1
  }
}
Run Code Online (Sandbox Code Playgroud)

A: BufferWriter符号表示,为了调用这个write方法,你需要有一个隐含的BufferWriter[A]得心应手.我们为他们提供了vals BufferWriters,所以我们应该设置.让我们看看这是否有效.

val b = ByteBuffer.allocate(6)
write(b, Array[Byte](1,2))
write(b, Array[Int](0x03040506))
scala> b.array
res3: Array[Byte] = Array(1, 2, 3, 4, 5, 6)
Run Code Online (Sandbox Code Playgroud)

如果你将这些东西放在一个文件中并开始在类中进行操作,javap -c -private你会看到正在使用适当的原始方法.

(注意,如果你没有使用专门化,这个策略仍然可以工作,但是它必须在循环内部装箱值以复制数组.)

  • 太棒了,正是我想要的!但是,如果不太重视@specialized功能,那就更好了.因为尽管它使代码更有效并因此对于实际使用是完美的,但它与问题没有直接关系,所以我担心这可能会使寻求答案的人略微混淆.类型类模式是这里的关键点.但除此之外,答案是完美的.谢谢,雷克斯! (5认同)

Dom*_*mra 16

使用类型类模式.它具有优于instanceOf检查(或模式匹配)类型安全的优点.

import java.nio.ByteBuffer

trait BufferWriter[A] {
  def write(buffer: ByteBuffer, a: A)
}

class BuffPimp(buffer: ByteBuffer) {
  def writeData[A: BufferWriter](data: A) = { 
    implicitly[BufferWriter[A]].write(buffer, data)
  }
}

object BuffPimp {
  implicit def intWriter = new BufferWriter[Int] {
    def write(buffer: ByteBuffer, a: Int) = buffer.putInt(a)
  }
  implicit def doubleWriter = new BufferWriter[Double] {
    def write(buffer: ByteBuffer, a: Double) = buffer.putDouble(a)
  }
  implicit def longWriter = new BufferWriter[Long] {
    def write(buffer: ByteBuffer, a: Long) = buffer.putLong(a)
  }
  implicit def wrap(buffer: ByteBuffer) = new BuffPimp(buffer)
}

object Test {
  import BuffPimp._
  val someByteBuffer: ByteBuffer
  someByteBuffer.writeData(1)
  someByteBuffer.writeData(1.0)
  someByteBuffer.writeData(1L)
}
Run Code Online (Sandbox Code Playgroud)

所以这段代码不是类型类的最佳演示.我对他们还很新.此视频详细介绍了它们的优势以及如何使用它们:http://www.youtube.com/watch?v = sVMES4RZF-8

  • +1 - 这是一个很好的答案,但还有一个额外的问题,即使使用数组,它也可以以全原始速度工作。 (2认同)
  • 它并没有让我觉得这是一个重大变化(它只是稍微更惯用,更有效),尤其是当他明确要求清理时。他深思熟虑的回答完好无损,只是略有增强。正如我上面所建议的,添加对数组的支持更像是对答案的实际更改,这就是为什么我没有自己制作并建议将更改作为评论的原因。 (2认同)