4

Scala では、次のことができます。

trait Api {
    def someApiCall: Either[Failure, GoodResult];
}

また

object SomeObject {
    type SomeResult = Either[Failure, GoodResult]
}

trait Api {
    def someApiCall: SomeObject.SomeResult;
}

前者は結果の型についてより明示的であるため、読みやすくなっていますが、異なる実装では、Either[...] を何度も再入力する必要があります。これは後者で解決されますが、読者は一見しただけでは結果について多くの結論を下すことができません。

戻り値の型がOptionの代わりである場合、Either当然、以前のバージョンに固執します。多くの型パラメーターを持つより複雑な型の場合、2 番目の方がより有益です。Eitherミッドフィールドのどこかにいます。

私の直感では、長期的には後者の方が維持しやすいということです。どう思いますか？これに関する慣行はありますか？

4

1 に答える 1

10

次のいずれかを実行します

  1. 明示的にとして宣言しEither[X, Y]ます。
  2. MaybeResult[Y]（for type MaybeResult[A] = Either[Failure, A]）として宣言します

率直に言って、それでも私はそれを明示的に宣言します。＃2（あなたの提案に対する）の利点は、標準Failureタイプ（おそらくExceptionまたはList[String]）を使用して、これを使用するすべての場所に個別のタイプエイリアスを宣言する必要がないことです。

使用する利点は、APIユーザーが何が起こっているのかEitherが100％明確になることです。ただし、さらに一歩進んでScalazを使用しますValidation。

def someApiCall : ValidationNEL[String, Result]

ここでの利点はValidation、Eitherがそうではない方法で構成可能であるということです（そうでなければ、それらは同型型です）。例えば：

def a(i : Int) : ValidationNEL[String, Float]
def b(f : Float) : ValidationNEL[String, Boolean]

次に、作成できます。

a(1) >>= b //ValidationNEL[String, Boolean]

そのようです：

scala>  def a(i : Int) : ValidationNEL[String, Float] = error("")
a: (i: Int)scalaz.Scalaz.ValidationNEL[String,Float]

scala> def b(f : Float) : ValidationNEL[String, Boolean] = error("")
b: (f: Float)scalaz.Scalaz.ValidationNEL[String,Boolean]

scala> lazy val c = a(1) >>= b
c: scalaz.Validation[scalaz.NonEmptyList[String],Boolean] = <lazy>
于 2011-04-01T12:24:21.527 に答える