У методов, заканчивающихся на _!
, таких как delete_!
или i_is_!
, есть особое значение? Являются ли они "просто именами"? Выполняют ли они какое-то соглашение? Там даже bulkDelete_!!
. (Конкретный контекст - "Лифт", если это имеет значение.)
Делайте методы, заканчивающиеся на _! имеют особое значение в Scala?
Ответ 1
Я не уверен, что соглашение предназначено для использования _!
и _!!
в Lift, но здесь немного фона.
Любой буквенно-цифровой идентификатор может иметь _ и список добавленных символов и все еще обрабатываться как один идентификатор. Например:
scala> class [email protected]%*!
defined class Example_$bang$at$percent$times$bang
(Фактически вы можете разбирать почти что-либо как идентификатор, если вы окружаете его обратными окнами - и это то, что вы делаете, если класс Java использует зарезервированное слово Scala, например. Или если вы хотите, чтобы в ваши идентификаторы.)
Однако компилятор распознает только один символический финал. Если есть метод, похожий на getter, то getter_ = будет интерпретироваться как сеттер. (Если вы на самом деле используете его в качестве сеттера, зависит от вас, у него будет семантика сеттера.) Итак,
scala> class Q { def q = "Hi"; def q_=(s: String) { println(s.reverse) } }
defined class Q
scala> val q = new Q
q: Q = [email protected]
scala> q.q
res0: java.lang.String = Hi
scala> q.q = "Could use this to set something"
gnihtemos tes ot siht esu dluoC
Кроме того, компилятор меняет порядок вызова и вызываемого абонента любым способом, заканчивающимся на :
. Это чаще всего встречается в списках: newElement :: existingList
на самом деле является вызовом existingList.::(newElement)
. Итак, например:
scala> object Caps { def to_:(s: String) = s.toUpperCase }
defined module Caps
scala> "Example" to_: Caps
res40: java.lang.String = EXAMPLE
Любое другое использование символов _
+ является условным.
Ответ 2
Никаких особых значений для! в именах Scala. В семействе языков Lisp,! часто используется для обозначения того, что функция имеет побочные эффекты, и это выглядит как соглашение здесь.
Ответ 3
Странно не упоминаемый до сих пор (хотя и не имеющий особого отношения к вашему вопросу) unary_! который обрабатывается специально.
scala> class A { def unary_! = 5 }
defined class A
scala> !(new A)
res0: Int = 5