我是
Scala的新手,但有一些
Java背景.
在编写Scala代码时,以这种样式处理Option参数很有用：
val text = Option("Text")
val length = text.map(s => s.size)
但每个s =>据我所知,s.size带来了一个新的Function1 [A,B].如果我做了8次这样的转换,它将带来8个额外的类.绑定表单时,我非常重视这些片段,所以问题是：
我应该少用它,也许用if-notation代替它,或者类似泛滥对JVM不是很关键,或者Scala编译器可能会做某种魔术？
更新：一个更具体的例子是：
case class Form(name: Option[String],surname: Option[String])
val bindedForm = Form(Option("John"),Option("Smith"))
val person = new Person
bindedForm.name.foreach(a => person.setName(a))
bindedForm.surname.foreach(a => person.setSurname(a))
它会产生两个不同的Function1 [String,String]类吗？如果有数百次此类转换怎么办？
解决方法
如果您正在为Android开发,那么您可能会使用Dalvik运行代码,这有一个恼人的64k方法限制(尽管有
are ways around it).由于每个类都需要几个方法(构造函数和应用程序),这可能是一个问题.
否则,Sun / Oracle JVM上的类进入PermGen空间,如果确实需要,可以在启动JVM时调整.这没关系.是的,你会有很多课程,也许会有成千上万,但是JVM可以很好地处理它(至少如果你愿意为它提供预期的预测).除非你知道你很可能遇到一些不寻常的约束,否则这不是你应该担心的事情.
更常见的是,人们可能会担心创建所有这些功能会对性能造成影响 – 但如果你现在没有真正遇到这种惩罚,也不要担心;这是Scala编译器原则上可以解决的问题,并且它一直变得越来越聪明.所以只需用惯用的方式编写代码,除非它现在是一个很大的性能问题,只希望编译器能够拯救你.这将是一个不错的机会,你会发现更容易以“正确”的方式编写它,然后在需要时重构性能,而不是采用使用更笨拙的构造的策略以防万一是个问题.当然,有些地方你可能事先知道肯定会成为一个瓶颈,就像把你从一个巨大的文件中读取的每个字节包装在一个选项中,但除了那些明显的东西之外,你最好还是反应性地做已知问题而不是主动避免关闭.
