这是在 Scala 中初始化空引用的正确方法吗?
假设我有一个未初始化的 MyObject
实例:
var a:MyObject = null
这是将其初始化为 null 的正确方法吗?
Let's say I have a MyObject
instance which is not initialized:
var a:MyObject = null
is this the proper way to initialize it to null?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
替代方案
使用
null
作为最后的手段。正如已经提到的,Option
取代了 null 的大部分用法。如果您使用null
来实现字段的延迟初始化并进行一些昂贵的计算,则应该使用lazy val
。规范初始化为 null
也就是说,Scala 确实支持
null
。我个人将它与 Spring 依赖注入结合使用。您的代码完全有效。不过,我建议您使用
var t: T = _
将t
初始化为其默认值。如果T
是原语,您将获得特定于该类型的默认值。否则你会得到null
。这不仅更简洁,而且当您事先不知道
T
是什么时,这是必要的:高级
使用
var t: T= null
是一个编译错误如果 T 是无界的:您可以添加一个隐式参数作为
T
可为空的证据 -AnyRef
的子类型而不是NotNull
的子类型不完全Alternatives
Use
null
as a last resort. As already mentioned,Option
replaces most usages of null. If you usingnull
to implement deferred initialisation of a field with some expensive calculation, you should use alazy val
.Canonical initialisation to null
That said, Scala does support
null
. I personally use it in combination with Spring Dependency Injection.Your code is perfectly valid. However, I suggest that you use
var t: T = _
to initializet
to it's default value. IfT
is a primitive, you get the default specific to the type. Otherwise you getnull
.Not only is this more concise, but it is necessary when you don't know in advance what
T
will be:Advanced
Using
var t: T= null
is a compile error if T is unbounded:You can add an implicit parameter as evidence that
T
is nullable -- a subtype ofAnyRef
not a subtype ofNotNull
This isn't fully baked, even in Scala 2.8, so just consider it a curiousity for now.规范的答案是不要使用 null。相反,请使用选项类型:
当您想要设置它时:
当您想要从中读取内容时,测试 None:
The canonical answer is don't use null. Instead, use an option type:
When you want to set it:
And when you want to read from it, test for None:
正如 David 和 Retronym 已经提到的,在大多数情况下使用
Option
是个好主意,因为Option
使您更明显地必须处理无结果的情况。但是,返回Some(x)
需要创建对象,并且调用.get
或.getOrElse
可能比 if 语句更昂贵。因此,在高性能代码中,使用Option
并不总是最好的策略(特别是在集合查找代码中,您可能会多次查找某个值,并且不希望相应地创建很多对象) 。话又说回来,如果您正在执行类似返回整个网页(可能不存在)的文本之类的操作,则没有理由不使用Option。另外,只是为了用
null
来补充一下关于泛型的反义词,如果你真的意味着它应该是null
,你可以以一种完全成熟的方式来做到这一点:这适用于2.7 和 2.8。它比
<:<
方法不太通用,因为它不遵守NotNull
AFAIK,但它在其他方面完全按照您希望的方式执行。As David and retronym have already mentioned, it's a good idea to use
Option
in most cases, asOption
makes it more obvious that you have to handle a no-result situation. However, returningSome(x)
requires an object creation, and calling.get
or.getOrElse
can be more expensive than an if-statement. Thus, in high-performance code, usingOption
is not always the best strategy (especially in collection-lookup code, where you may look up a value very many times and do not want correspondingly many object creations). Then again, if you're doing something like returning the text of an entire web page (which might not exist), there's no reason not to use Option.Also, just to add to retronym's point on generics with
null
, you can do this in a fully-baked way if you really mean it should benull
:and this works in 2.7 and 2.8. It's a little less general than the
<:<
method, because it doesn't obeyNotNull
AFAIK, but it otherwise does exactly what you'd hope it would do.我遇到了这个问题,因为 scalastyle 告诉我在使用
null
初始化测试中的对象时不要使用 null。我的解决方案无需更改任何满足 scalastyle 的类型:
I came across this question since scalastyle told me to not use null when initialising an object within my test with
null
.My solution without changing any type that satisfied scalastyle: