2010-12-04 4 views
13

私はLiftフレームワークのソースコードを読むことを開始します。methodName_?のような名前を使用して非常に多くのメソッドが定義されていますが、_?には特別な意味がありますか?なぜ人々は_を使用しますか?識別子接尾辞として?

def empty_? : Boolean = {} 
+0

似たような質問:http://stackoverflow.com/questions/1598410/use-of-special-characters-in-function-names – aioobe

答えて

24

?これは述語、Booleanを返す関数であることを示します。このコンベンションは、?(Scheme)、pまたは-p(疑問符を「類似」文字でシミュレートする他のLisps)も述語を意味するLispに戻ります。 「オブジェクトは空ですか?」という質問をしていると考えてください。

スカラーでは、別々の識別子名(英数字と句読点を含む)を_で区切った場合にのみ使用できます。例えば、

scala> def iszero?(x : Int) = x == 0 
<console>:1: error: '=' expected but identifier found. 
     def iszero?(x : Int) = x == 0 
       ^

は動作しませんが、

scala> def iszero_?(x : Int) = x == 0   
iszero_$qmark: (x: Int)Boolean 

はありません。

+1

質問をあまりにも早く読んでください。私は私を削除し、これを投票しました。 – duffymo

26

リフトフレームワークの外にコンストラクトが見えることはほとんどありません。私はそれが主にルビー羨望だと思う。

他のほとんどのScalaプロジェクトは、この構文を恥ずかしがります。末尾の疑問符ではなく、アンダースコアをコードに導入するもう1つの方法であるため、シンボルはあまりにも過負荷になっています。

複数のScalaプロジェクトの評価に基づいて、表記法は非慣用的であると合理的に説明することができます。

x?y 

?があると

x.?(y) 

として読まれるだろう:

UPDATE

下線が必要であることの理由は、ここで、インフィックス表記から明確になりますメソッド名。一方:

x_?y 

明らかにデマークx_?はアトミックです。

構文は正式に「混合識別子」として知られているものの一例であり、同様の構築物が使用される場合、(おそらく)ハッキングと考えられるよう

def prop_=(v:String) = ... //setter 
def unary_- = ... //prefix negation operator 

として定義を可能にするように意図されています単にメソッド名の最後に疑問符を表示するだけです。

+3

"シンボルがすでに過大に過負荷になっています"別のトークンとして、識別子内にはありません。 –

+3

@Alexey Romanov:それでも、これはCamelCaseとdromedaryCaseを識別子で使うScalaの規約に反するものです。 –

+0

ええ、あまりにも多くのScalaのソースコードに下線を引いています。Liftでは、ParsePath(List( "account"、acctName)、_、_、_)、_、_)のような下線がありますが、このようにたくさんのParsePathを記述する必要があります。 – Sawyer

関連する問題