私はスカラ座を読んでいると私は疑問に思って中...
なぜ持つための任意の理由 "valの容量を:INT" ではなく "ヴァルのInt容量" のスカラ
val capacity : Int
代わりの
val Int capacity.
この選択がなされた理由は何ですか?もしそうでなければ、それを宣言するJavaの方法から離れていくのは良い選択ではないように思えます。 JavaからScalaへの移行が容易になりました(少しではなく、少しでも)
私はスカラ座を読んでいると私は疑問に思って中...
なぜ持つための任意の理由 "valの容量を:INT" ではなく "ヴァルのInt容量" のスカラ
val capacity : Int
代わりの
val Int capacity.
この選択がなされた理由は何ですか?もしそうでなければ、それを宣言するJavaの方法から離れていくのは良い選択ではないように思えます。 JavaからScalaへの移行が容易になりました(少しではなく、少しでも)
大部分の時間はIntパートを離れることができるためです。 Scalaは、Javaよりも型推論のシステムがはるかに優れています。
x:Tは、ロジックおよび多くのプログラミング言語の種類の標準表記法です。 Cとその子孫は、Javaの中で、これから逸脱しています。しかし、Cの型表記は実際にはひどい(mapのような中程度に複雑な高次関数の型を書き留めようとする)。
また、この表記法を使用すると、(Wysawygが既に書いたように)型を外すことや、式の中に型を追加することは簡単です。
はここWysawygの声明に例を示します
val capacity = 2
しかし、あなたは通常、ちょうどval
でこれをしない場合があります。
trait Foo {
def capacity = 2 // Allow child classes to override and decide the value later
}
// Force instances of Bar to set the value
class Bar(override val capacity : Int) extends Foo
// Have Bat determine it on the fly
trait Bat extends Foo {
def onlyAThird : Int
override def capacity = onlyAThird * 3
}
(私は、何の書式設定をコメントとしてこれを挿入しようとしない、悲しいかな。)
なぜリテラル定数に 'def'を使用しますか?さらに、 'def'は偶然に' default'と説明されているようです。 –
ああ、 'def'は約評価時間です。もし私たちが 'val capacity = 2'と言ったら、' Bat'はその場で容量を決める関数で 'Foo'を拡張させることはできません。 –
私は今理解していると思います。あなたはそれをメソッドによってオーバーライド可能にするために 'def'と定義するだけです。valは別のvalによってのみオーバーライドできます。 –
私はダニエルがそのようなことを考えたと思う:
val a = 7
val b: Int = 8
var x = "Foo"
var y: String = "Bar"
def sum (a: Int, b: Int) = a + b
def mul (a: Int, b: Int): Int = a * b
をタイプは、多くの場合、推論することができます。
私はMartin Odersky自身の声明を読んでいると思います。これは、可読性を向上させるためにこの決定も行われたということです。確かにそうです。
val number : Double = ...
val something : Array[(Seq[String], Map[Seq[String], Double])] = ...
val pattern : String = ...
あなたは名(視覚的に)速いの参照/ mathodsの、ないタイプを見つける必要がある時間のほとんどを
val Double number = ...
val Array[(Seq[String], Map[Seq[String], Double])] something = ...
val String pattern = ...
を比較します。
タイプの有無にかかわらず例を追加すると、その理由がより明確になります。 –
に依存します。時には、右側のサイトが複雑な場合(特にAPIを構築する場合)、コンパイル時に多くのバグをキャッチするので、型に注釈を付ける必要があります。 – Raphael