Сделайте методы, заканчивающиеся _! имеет особое значение в Scala?
Сделайте методы, заканчивающиеся _! такой как delete_! или i_is_! имеет особое значение? Они, "просто называет"? Они следуют некоторой конвенции? Там ровно bulkDelete_!!. (Определенный контекст является Лифтом, если это имеет значение.)
3 ответа
Я не знаю, каково соглашение об использовании _! и _ !! в Lift, но вот немного предыстории.
К любому буквенно-цифровому идентификатору можно добавить _ и список символов, и при этом его можно будет анализировать как единый идентификатор. Например:
scala> class Example_!@%*!
defined class Example_$bang$at$percent$times$bang
(Фактически, вы можете проанализировать почти что угодно как идентификатор, если окружите его обратными кавычками - и это то, что вы делаете, например, если класс Java использует зарезервированное слово Scala. Или если вам нужны пробелы в ваших идентификаторах.)
Однако компилятор специально распознает только одно символическое окончание. Если есть метод, который выглядит как получатель, то getter_ = будет интерпретироваться как установщик. (Действительно ли вы используете как сеттер, зависит от вас; в любом случае он будет иметь семантику сеттера.) Итак
scala> class Q { def q = "Hi"; def q_=(s: String) { println(s.reverse) } }
defined class Q
scala> val q = new Q
q: Q = Q@b5c12e
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
Любое другое использование символов _ + является условным.
В ! в названиях Скала. В семействе языков на основе Lisp, ! часто используется для указания на то, что функция имеет побочные эффекты, и это выглядит как соглашение здесь.
Как ни странно не упомянутое до сих пор (хотя и не имеет отношения к вашему вопросу) unary_! который лечится специально.
scala> class A { def unary_! = 5 }
defined class A
scala> !(new A)
res0: Int = 5