执行以 _ 结尾的方法!在Scala中有特殊含义吗?
以 _!
结尾的方法(例如 delete_!
或 i_is_!
)是否有特殊含义?它们“只是名字”吗?他们遵循一些惯例吗?甚至还有bulkDelete_!!
。 (如果有影响的话,具体上下文是“Lift”。)
Do methods ending with _!
such as delete_!
or i_is_!
have a special meaning? Are they "just names"? Do they follow some convention? There's even bulkDelete_!!
. (The specific context is Lift if it makes a difference.)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我不确定在 Lift 中使用
_!
和_!!
的约定是什么,但这里有一些背景知识。任何字母数字标识符都可以添加 _ 和符号列表,并且仍然被解析为单个标识符。例如:(
事实上,如果用反引号括起来,您几乎可以将任何内容解析为标识符——例如,如果 Java 类使用 Scala 保留字,您就可以这样做。或者如果您希望标识符中包含空格.)
然而,编译器仅识别一种特殊的符号结尾。如果有一个看起来像 getter 的方法,那么 getter_= 将被解释为 setter。 (您是否真的使用它作为setter取决于您;无论如何,它都会具有setter的语义。)因此,
此外,编译器会颠倒中调用者和被调用者的顺序任何以
:
结尾的方法。这在列表中最常见:newElement::existingList
实际上是对existingList.::(newElement)
的调用。因此,例如:_
+ 符号的任何其他用法都是约定。I'm not sure what the convention is for using
_!
and_!!
in Lift, but here's a bit of background.Any alphanumeric identifier can have _ and a list of symbols added and still be parsed as a single identifier. For example:
(In fact, you can parse almost anything as an identifier if you surround it with backticks--and this is what you do if a Java class uses a Scala reserved word, for example. Or if you want spaces in your identifiers.)
The compiler only recognizes one symbolic ending specially, however. If there is a method that looks like a getter, then getter_= will be interpreted as a setter. (Whether you actually use it as a setter is up to you; it will have the semantics of a setter, anyway.) So
In addition, the compiler reverses the order of caller and callee in any method that ends in
:
. This is most often seen in lists:newElement :: existingList
is actually a call toexistingList.::(newElement)
. So, for example:Any other usage of
_
+ symbols is convention.没有什么特殊含义!在 Scala 名称中。在基于 Lisp 的语言家族中,!通常用于指示函数有副作用,这看起来是这里的约定。
There are no special meanings to the ! in Scala names. In the family of Lisp-based languages, ! is often used to indicate that a function is has side-effects, and that looks to be the convention here.
奇怪的是,到目前为止没有提到(虽然与你的问题不是特别相关)是unary_!这是经过特殊处理的。
Strangely unmentioned thus far (though not particularly relevant to your question) is unary_! which is treated specially.