缺少第三方库是否会妨碍您使用Scala?

Pimp my Library

每当Java库的接口在Scala中有点麻烦时,这是一种使它更方便、代码更优雅的好方法。这里有一个非常简单的例子。我想在代码中一直使用scalaxml漂亮的打印机来返回格式良好的XML。这是正常的方法:

class Service {
val pp = new scala.xml.PrettyPrinter(80,2)
def content = 
  pp.format(<foo><bar>{something()}</bar></foo>)
}

然而,因为我一直这样做,我把这个添加到我的包

import scala.xml.Elem

object PrettyXml {
  val pp = new scala.xml.PrettyPrinter(80,2)
}

trait PrettyXml {
  case class Formatted(xml:Elem) { 
    def pretty = PrettyXml.pp.format(xml) 
  }
  implicit def toFormatted(xml:Elem) = Formatted(xml)
}

现在我可以用

class Service extends PrettyXML {
  val pp = new scala.xml.PrettyPrinter(80,2)
  def content = 
    <foo><bar>{something()}</bar></foo> pretty
}

如果我不想让它成为一种特性,我可以把PrettyXML放在一个package对象中。

我不太明白你的担心。Java库通常是一个.jar文件(压缩的.class文件集)。您希望Scala库是什么?嗯,这将是一组压缩的.class文件。这两种语言都编译成Java字节码!所以,回答你的问题:

还有人认为第三方库(与Java相比)的减少是在商业项目中使用Scala的障碍吗?

不,不是真的。

如果您将java库看作一个编译过的.jar文件,则不必跨两种不同的语言。

编辑:当然,Scala有一个非常丰富的类型系统,编译的类文件不能充分利用它。相反,大量可用的Java字节码格式的有用库可能使Scala 更多 比其他新的(现代的)语言更有吸引力。

这其实并不像看上去那么愚蠢和误导的问题。关于Scala中的库的一些事实:

2. 从Scala访问本机Java库要比从Java访问Java库稍微愉快一些,但只是稍微愉快一些。这里的问题是,本机Java库的级别远远低于用Scala编写的本机库或Java库的良好Scala包装器。原生Java库往往充斥着单一的方法接口(应该是函数)、轻描淡写的可空参数或返回(应该是选项)、不必要的并行类构造或“助手”(应该是特征)、手工编写的不太标准的迭代器,尝试一下要求块的资源管理(由于缺少闭包)和类型签名(尤其是Java-1.5之前的库),它们都是非常粗糙的。Scala程序员将Java库视为“完成工作所必需的”,而不是您真正期待的操作,这并不奇怪。
3. 通过包装或pimping,实际上很容易获得一个Java本机库,并使其与Scala本机库一样令人愉快地使用。我希望大多数主要企业库的Scala适配器在短期内都能提供。