DEV Community: 青年失業家だねぴょん

そうだARROWを入れてみよう

青年失業家だねぴょん — Mon, 17 Sep 2018 06:02:31 +0000

ARROWを触ってみたいけど、周りにARROWを触っている人が居ない…とかそんな（どんな）人向け

結論

公式DocumentのBeginnerタグ（？）ついているのを読むとか。

Option
Either
Try

あとは試しに使ってみて…大丈夫ほら、一回だけなら…

ってことで、最初にこの辺知ってたら楽しいかも？みたいなのを雑に紹介。

Option

kotlinのNullSafety(というかNullableというか)は便利だけどなぁ…
というあなたのために。

「NullSafety(というかNullableというか)じゃだめなの？？」という人は「Nullable Option」とかでググると色々な記事が出てくると思いますので、
なるほど！！ってなった場合に特におすすめです（ここでのチャーンレート高そうだ）

アプローチが違うというか…でもほら、一回使ってみるだけなら…

fun <A> convertSample(src:A?) {
    val a:Option<A> = Option.fromNullable(src)
    val b:Option<A> = src.toOption()
}

fun <A> convertSampleFromNonNull(src:A) {
    convertSample(src)
    val a:Option<A> = Option(src)
    val b:Option<A> = Option.just(src)
    val c:Option<A> = src.some()
}

といろいろとありますが、まあtoOption()で統一しておけば良いんじゃないでしょうか？

チョット特殊例？
FunctionalJavaでOption#iifとか使っていた人向け
いやまあそんな人がこのブログ見て得られるものってあるのかというのは置いといて…

fun condition(...):Boolean = ...

fun returnValue():A

val a:Option<A> = condition(...).maybe{ returnValue() }

Booleanにmaybeという拡張関数が生えているで、そちらで

例

fun <A, B, C> nonErrorMethod(a: A, b: B, c: C): Result {
    // エラーも副作用もないような処理
}

fun <A, B, C> kotlinSample(a: A?, b: B?, c: C?) {

    val result1: Result? = if (a != null && b != null && c != null) {
        nonErrorMethod(a, b, c)
    } else {
        null
    }

    val result2: Result? = a?.let { nonNullA ->
        b?.let { nonNullB ->
            c?.let { nonNullC ->
                nonErrorMethod(nonNullA, nonNullB, nonNullC)
            }
        }
    }
}

fun <A, B, C> useArrowSample(a: A?, b: B?, c: C?) {
    val optionA = a.toOption()
    val optionB = b.toOption()
    val optionC = c.toOption()

    val result1:Option<Result> = optionA.flatMap { nonNullA ->
        optionB.flatMap { nonNullB ->
            optionC.map{ nonNullC ->
                nonErrorMethod(nonNullA, nonNullB, nonNullC)
            }
        }
    }

    val result2: Option<Result> = Option.monad().binding {
        val a:A = optionA.bind()
        val b:B = optionB.bind()
        val c:C = optionC.bind()

        nonErrorMethod(a, b, c)
    }.fix()


    val result3: Option<Result> = Option.applicative()
        .map(optionA, optionB, optionC) { (a, b, c) -> nonErrorMethod(a, b, c) }.fix()
}

多分だいたいこんな感じでしょう。
何れの場合も引数の何れかがNull/Noneの場合、結果もNull/Noneになりますね。

monadとかapplicativeとか出てきていますが、
一旦は↑のサンプルみたいな挙動をするようになる便利な構文…で良いと思います。
特に前者はScala使っている人とかにはfor式チックなやつ…とかで…

具体的には

Option.monad().binding{...}.fix()でくくると、
... の中でOption<X>に対して.bind()ってメソッドが生える
呼ぶとOptionがNoneだったら処理を抜けてNoneを返し
SomeだったらXを返して次へ進む

Option.applicative()(aOption,bOption,cOption,..., {(a,b,c,...) -> ... }).fix()
で、aOption,bOptino,cOption,... の全部がSomeだった場合だけ、最後の引数で渡したメソッドが実行される

みたいな。

怖い人に怒られそうだけど、そんな感じで良いと思います。

reference

下記にもっと書いてある
https://arrow-kt.io/docs/datatypes/option/

Either

個人的な印象なのですが、LiveDataとかObservable各種を使っていると、
この手のものを自前で実装する(したくなる)ケースが多いと思います。
成功時だけじゃなくて失敗時も伝搬させたい…みたいな

例えばこのへんのSlideだったり

そんなあなたのために、ちゃんと用意されています。

例


sealed class MyError(val msg:String)
object MyError1 : MyError("error 1")
object MyError2 : MyError("error 2")

val liveData:LiveData<Either<MyError, Result>> = MutableLiveData()

liveData.observe(..., Observer{ either ->
    handlingSample(either)
})

fun handlingSample(either: Either<MyError, Result>) {
    val result1: String = either.fold(
        {
            error ->    
            error.msg
        },
        {
            res ->
            "success"
        }
    )

    val result2: String = when (either) {
        is Either.Left -> when (either.a) {
            MyError1 -> "MyError1 ${either.a}"
            MyError2 -> "MyError2 ${either.a}"
        }
        is Either.Right -> "success"
    }
}

fun aEither():Either<MyError, A>
fun bEither():Either<MyError, B>
fun cEither():Either<MyError, C>

fun useArrowSample() {

    val result1 = aEither().flatMap { a ->
        bEither().flatMap { b ->
            cEither().map { c ->
                nonErrorMethod(a, b, c)
            }
        }
    }

    val result2: Either<MyError, Result> = Either.monad<MyError>().binding {
        val a = aEither().bind()
        val b = bEither().bind()
        val c = cEither().bind()
        nonErrorMethod(a, b, c)
    }.fix()

    val result3: Either<MyError, Result> =
            Either.applicative<MyError>().map(aEither(), bEither(), cEither()) { (a, b, c) -> nonErrorMethod(a, b, c) }.fix()
}

上の方はLiveDataでエラーのときもなんかしたい（この場合タダStringにまるめているだけですが…）とかの雑なサンプルを

後半部分は、なんかOptionの時とよく似てますね？

これ素直なKotlinで書くってなるとどう書くんでしょうか…
LiveDataとかで伝搬させるためのクラスを作る感じになると思うので、GoogleSamplesとかだとこの辺とか…？

reference

下記にもっと色々と書いてある
https://arrow-kt.io/docs/datatypes/either/

Try

似たようなので（？）1.3-M1でSuccessOrFailureとかあるけどなんかこれ…
we discourage using SuccessOrFailure as return type of functions ってことらしいし
この方のコメントで言われているぐらいに捉えたほうが納得するというか？
This SuccessOrFailure class SHOULD NOT be used directly as a return type only in case the failure is handled by the caller locally. Where nullable type and sealed class hierarchy could be used instead.
そうすればこの辺の構文がわからんでもないというか...

いやまあ使ってわかりやすいのかこれ…

まあ1.3でたらわかるでしょうし、長いものには巻かれます。
ちなみにM2で触れられているContractsのほうが気になっていますし、欲しい。

Contracts構文素敵じゃないですか？
Internalでは1.1か2くらいから使われていたんだし、はよ出してくれ。

例

多分もう想像つくかと


sealed class MyError(val msg:String): Throwable(msg)
object MyError1 : MyError("error 1")
object MyError2 : MyError("error 2")

val liveData:LiveData<Try<Result>> = MutableLiveData()

liveData.observe(..., Observer{ _try ->
    handlingSample(_try)
})

fun handlingSample(src: Try<Result>) {
    val result: String = src.fold(
            { error ->
                when (error) {
                    is MyError1 -> error.msg
                    is MyError2 -> error.msg
                    else -> "unknown error"
                }
            },
            { res ->
                "success"
            }
    )
}

fun aSometimeThrow():A
fun bSometimeThrow():B
fun cSometimeThrow():C
fun aTry():Try<A> = Try{ aSometimeThrow() }
fun bTry():Try<B> = Try{ bSometimeThrow() }
fun cTry():Try<C> = Try{ cSometimeThrow() }

fun kotlinSample() {
    try {
        val a = aSometimeThrow()
        val b = bSometimeThrow()
        val c = cSometimeThrow()
        nonErrorMethod(a, b, c)
    } catch (e:MyError) {
        // ...
    } catch (e:Throwable) {
        // ...
    }
}

fun useArrowSample() {

    val result1:Try<Result> = aTry().flatMap { a ->
        bTry().flatMap { b ->
            cTry().map { c ->
                nonErrorMethod(a, b, c)
            }
        }
    }

    val result2: Try<Result> = Try.monad().binding {
        val a = aTry().bind()
        val b = bTry().bind()
        val c = cTry().bind()
        nonErrorMethod(a, b, c)
    }.fix()

    val result3: Try<Result> =
            Try.applicative().map(aTry(), bTry(), cTry()) { (a, b, c) -> nonErrorMethod(a, b, c) }.fix()

    // call handlineSample etc...        
}

なんていうかびっくりするくらいOption版のコピペですね！

reference

Tryに関しては結構色々なHandling方法や、Eitherへの変換とかあるので見ておいて損ないです
Either<Throwable,...>に便利メソッド生やしたって読み替えても良いと思います(雑)

https://arrow-kt.io/docs/datatypes/try/

中間まとめ

ところどころドキュメント古い

正直この記事書く意味有るのかわからないくらい、公式Document充実しています。
が、注意する場所も…

Kotlin Slackの#arrowで
we're deprecating ForXX extensions in favor of generating the extension functions directly on the types
と言っていますので、

ForOption extensions {
    binding {
        ...
    }
}

を

Option.monad().binding {
    ...
}

とかと読み替えておく必要はありそうです。

他

Option/Either/Tryの利用例が似ているというか一緒ですよね。
ということは、実は大体他に用意されているやつもおんなじように使えるようになっています。

ただのInterfaceっぽいですよね。

実はそれがM的なあれに…みたいなこと書くとアチラコチラから刺されそうですが…
ここの説明とか読むとなんか納得してもらえるんじゃないかな

とはいえここ見ている人は多分英語辛い派閥でしょうから、
上のリンクの「サンプルコードだけをゆっくり読めば」なるほど感になるのでは？？

疲れたので雑にいくつか

途中Eitherとかで包んでないんだけどよしなに包んで欲しい

val res1 = Either.monadError<Throwable>().bindingCatch {
    val a = Either.right(1).bind()
    val b = throwError() // ここでLeftになって返る
    a + b
}.fix()

val res2 = Try.monadError().bindingCatch {
    val a = Try.just(1).bind()
    val b = throwError() // ここでFailureになって返る
    a + b
}.fix()

monad().binding{...} → monadError().bindingCatch{...}に置き換えるとあら不思議

ただし、何でもかんでもbindingCatchが呼べるわけじゃないので…
IDEの補完で気がつくと思いますのでそれで。

Eitherの場合、LeftがThrowableなものに限定されます

ドキュメント的にはこのへん

rxjavaチックにThread切り替えたい

Single.just(...)
    .map(...)
    .observeOn(Schedulers...)
    ...
    .subscribeOn(AndroidSchedulers...)
    ...

的なやつ

このへんとか
 このへん

根本的にタダの非同期処理として使う場合での比較という点はお間違えなく。

ちなみにメソッドチェーンで繋がなくてもできます

val (res1, disposable1) = IO.async().run {
    bindingCancellable {
        continueOn(Unconfined)
        val a = IO.just(1).bind()
        val b = throwError()
        a + b
    }
}

res1.fix().attempt().unsafeRunSync().fold(
        {
        },
        {
            fail()
        }
)

val (res2, disposable2) = DeferredK.async().run {
    bindingCancellable {
        continueOn(Unconfined)
        val a = DeferredK.just(1).bind()
        val b = throwError()
        a + b
    }
}

res2.fix().unsafeRunAsync {
    it.fold(
            {
            },
            {
                fail()
            }
    )
}

こんな感じとか。
さっきのbindingCatchの更に上位版みたいな（？）やつでCancellableというのがあります。
こうすると、戻り値がTupleになって、戻り値の2個めがCancel用のものになっています。

書き方が色々とあるのは良いのか悪いのか…

上の例だと disposable1() とかでCancelされます

このへんとか

`List<Option<Int>>`みたいなのが、`Option<List<Int>>`にならないかな？

これ、SuccessOrFailureの記事でもList<SuccessOrFailure<String>>みたいなの出てきてて思い出しました。
SuccessOrFailure<List<String>>みたいにしたい！とかありそうな気がするんですけども…
(まあError複数ある場合の処理を期待しているときはあれだが)

最後にReturnされるものがList<Option<Int>>とかだったら中身精査しろよ感ありますが、
処理の途中でOption<...>だったらflatMapに食わせられるのに…とかそんな時用途でしょうか。

val src = listOf(1, 2, 3, 4)
val target:List<Option<Int>> = src.map { (it % 2 == 0).maybe { it } }

val actual:Option<List<Int>> = target.k().sequence(Option.applicative()).fix()

assertEquals(actual, None)

val target2:List<Try<Int>> = src.map {
    Try {
        if (it % 2 == 0) it
        else throw Exception("$it")
    }
}

val actual2:Try<List<Int>> = target2.k().sequence(Try.applicative()).fix()

actual2.fold(
        {
            assertTrue(it.message == "1")
        },
        {
            fail()
        })

上の例だとそもそも奇数フィルターしろや案件ですがそのへんはまあ…例なので…
sequenceとapplicativeというワードを覚えておくと良いことあるかもしれません。

これ、公式Documentだとどこなんでしょう…
Traverseあたりにそのうち書かれるのかな？
https://arrow-kt.io/docs/typeclasses/traverse/#traverse

もっと強力な使い方無いの？？

Option<Either<X,Y>>みたいなのをキレイに（ネスト無く）使いたい！
とかになってくると、
OptionTとか
EitherTとか知りたくなるかと思います。

あとAndroidで…という文脈では余り使う機会が想像できないけど、
意味がわかるとなるほど！！って思えるのがValidatedとEitherを切り替えるサンプルかと思います。

このサンプルだと、FormのFieldの入力をラベル、アドレス両方まとめてチェックしますが、
多分Android（というかフロントというか）だと、入力フォームそのものに（入力した端から）Validationをかけて、そのまま最初のErrorだけ表示

で、そのValidation(たち)を通ったものだけが伝搬してくるようにするかと思うので…

なんかあえてこっちを(特にValidatedを)使うケースがぱっと想像つかないんですよね。（あくまでもAndroid脳だと？）
なおこの辺がサンプルとしてあります。

ただ、このサンプルから学べることはいっぱいあると思うのでおすすめです。

まあ入れたらフル機能使わなければならない！なんてルールは無いですし、
Option/Eitherあたりから始めて、良かったら他のも試してみればよいかと思います。

終わり

なんか間違っていたり、もっとここんとこ書いて欲しい！とかありましたら、雑にご連絡ください。
.k()とかKind<F,A>とかの説明とかが喜ばれたりするんでしょうか？？？
気が向いたら書きます。

Thanks Rx and Hello Arrow for Androider

青年失業家だねぴょん — Thu, 02 Aug 2018 17:31:17 +0000

備忘を兼ねてこんにちは
タイトルは大げさで、非同期処理に置いてArrowを使ってみても良いかもしれない 程度です。

完全なサンプルはこちら

まずは使ってみる

@Throws(Exception::class)
fun tooSlowMethod():Result = ...

Single.create<Result> { emitter ->
    try {
        emitter.onSuccess(tooSlowMethod())
    } catch (e: Exception) {
        emitter.onError(e)
    }
}
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe({
            ..
        }, {
            ..
        })

これを書き直していきましょう。

まずはただcoroutine使ってみただけ。

launch(UI) {
    try {
        val res = withContext(DefaultDispatcher) { tooSlowMethod() }
        ..
    } catch (e: Exception) {
        ..
    }
}

arrow版(そしてこれはまだ未完成)

DeferredK { tooSlowMethod() } // or async { tooSlowMethod() }.k() etc...
    .unsafeRunAsync{ either ->
        either.fold(
            ..
        },{
            ..
        })

書き方は色々とありますが、とりあえずこんな感じでしょうか？？

ただし次の条件で一気に弱くなります…

fun isMainThread() = Looper.myLooper() == Looper.getMainLooper()

fun successProcess(result: Result) {
    if (!isMainThread()) throw RuntimeException("＼(^o^)／")
    Log.d("test", "success $result")
}

fun errorProcess(e: Throwable) {
    if (!isMainThread()) throw RuntimeException("＼(^o^)／")
    Log.d("test", "error", e)
}

Single.create<Result> { emitter ->
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe({
            successProcess(it)
        }, {
            errorProcess(it)
        })

launch(UI) {
    try {
        val res = withContext(DefaultDispatcher) { tooSlowMethod() }
        successProcess(res)
    } catch (e: Exception) {
        errorProcess(e)
    }
}

// ＼(^o^)／
DeferredK{...}
    .unsafeRunAsync({successProcess(it)}, {errorProcess(it)})

Androidあるあるですね。

/**
 * 実装はunsafeAsyncRunとほぼ同じだが、Callback時のRunContextを選択できるようにしている
 * どうせ今回のケースだとEitherに対してfoldする(偏見)し、そこも展開してみた
 * Eitherに対してパターンマッチで…の場合もあるかもなので、お好みで
 */
fun <A> DeferredKOf<A>.unsafeRunAsyncWrapper(runContext: CoroutineContext, ifError: (Throwable) -> Unit, ifSuccess: (A) -> Unit) {
    async(Unconfined, CoroutineStart.DEFAULT) {
        Try { await() }.fold(
                { withContext(runContext) { ifError(it) } },
                { withContext(runContext) { ifSuccess(it) } })
    }.let {
        it.invokeOnCompletion { a: Throwable? ->
            if (a != null) throw a
        }
    }
}

DeferredK {
    tooSlowMethod()
}.unsafeRunAsyncWrapper(UI, { errorProcess(it) }, { successProcess(it) })

なんかすっごいRxっぽく(?)なりましたね。

むしろasyncとRxの良いとこ取りっぽく感じませんか（感じませんね）

もうちょっと使ってみる

基本的に現実は厳しいので、もうちょっと現実に即してみましょう。

fun slowMethodA(): ResultA {
    if (isMainThread()) throw RuntimeException("＼(^o^)／")
    ..
}

fun slowMethodB(): ResultB {
    if (isMainThread()) throw RuntimeException("＼(^o^)／")
    ..
}

fun makeResult(a: ResultA, b: ResultB): Result {
    ..
}

// DeferredKによって作られたThread上で動く
fun run1(): DeferredK<Result> {
    return DeferredK {
        Log.d("test", "pre a running thread is ${Thread.currentThread()}")
        val a = slowMethodA()

        Log.d("test", "pre b running thread is ${Thread.currentThread()}")
        val b = slowMethodB()

        Log.d("test", "pre makeResult running thread is ${Thread.currentThread()}")
        makeResult(a, b)
    }
}

// 呼び出し側で作られたThreadで始まり、DeferredKで作られたThreadに切り替わりながら動く
fun run2(): DeferredK<Result> =
        ForDeferredK extensions {
            binding {
                Log.d("test", "pre a running thread is ${Thread.currentThread()}")
                val a = DeferredK { slowMethodA() }.bind()

                Log.d("test", "pre b running thread is ${Thread.currentThread()}")
                val b = DeferredK { slowMethodB() }.bind()

                Log.d("test", "pre makeResult running thread is ${Thread.currentThread()}")
                makeResult(a, b)
            }.fix()
        }

// 呼び出し側がmain threadだと死ぬ
fun run3(): DeferredK<Result> =
        ForDeferredK extensions {
            binding {
                Log.d("test", "pre a running thread is ${Thread.currentThread()}")
                val a = DeferredK.just(slowMethodA()).bind()

                Log.d("test", "pre b running thread is ${Thread.currentThread()}")
                val b = DeferredK.just(slowMethodB()).bind()

                Log.d("test", "pre makeResult running thread is ${Thread.currentThread()}")
                makeResult(a, b)
            }.fix()
        }

// bindingの中身は呼び出し側だが、各slowMethod内はCommonPoolを利用したものになる
fun run4(): DeferredK<Result> =
        ForDeferredK extensions {
            binding {
                Log.d("test", "pre a running thread is ${Thread.currentThread()}")
                val a = { DeferredK.just(slowMethodA()) }.bindIn(CommonPool).bind()

                Log.d("test", "pre b running thread is ${Thread.currentThread()}")
                val b = { DeferredK.just(slowMethodB()) }.bindIn(CommonPool).bind()

                Log.d("test", "pre makeResult running thread is ${Thread.currentThread()}")
                makeResult(a, b)
            }.fix()
        }

突然のFor構文出てきましたが、あえて何も説明しません。

あれです、あれ。

なんか書けって言われたら考えますので雑に連絡ください。

さて、各々の違いは各メソッドのコメントに書いてあるとおりです。

これらの処理の共通点は

すべて直列に動く

です

あとmakeResultによる結果も(副作用なければ)全部一緒です。

書き方によって動作するThreadが違いますので、その点をちゃんと考慮しながら…

というのが必要かと思います。

まあでも直列だけじゃなくて当然並列に動かしたいですよね…？

fun runParallels1(): DeferredK<Result> {
    val a = DeferredK { slowMethodA() }
    val b = DeferredK { slowMethodB() }
    return a.flatMap { aa -> b.map { makeResult(aa, it) } }
}

fun runParallels2(): DeferredK<Result> =
        ForDeferredK extensions {
            binding {
                val a: DeferredK<ResultA> = DeferredK { slowMethodA() }
                val b: DeferredK<ResultB> = DeferredK { slowMethodB() }
                makeResult(a.bind(), b.bind())
            }.fix()
        }

slowMethodA/Bがthrowを返すようなパターンだった場合のHandlingがチョットややこしくなるかと思います。

またあえて型を明示しましたが、bindしたほうがResultA/Bを直接見れて、For構文的な嬉しさを感じるかと思います。

並列動作版は呼び出しメソッドが単体で動いて且つ失敗しないようなもののときに検討すると良いんじゃないでしょうか？

(別にDeferredKに限った話ではない)

最後に

これだけだとArrowをAndroidに突っ込む動機としては弱いと思います。

ただ、

kotlinのDeferredにmap/flatMapとかとか欲しいなー
非同期処理だけだとRx重厚(お前が言うな)だよなぁ…

ってチョットでも思ったなら少し触ってみる価値はあると思います。

気が向いたらEitherTransformerあたりの例でも書きます。

待ちきれない…って人は、公式Documentが良いと思います。

ていうか公式Documentが良いです。

その他Arrowのアプリ導入相談とかお受けしますので、お気軽に。(そんなやつ居るか？)

Reference

Arrowの公式ドキュメントのkotlinxcoroutinesの項目
For構文のbind/bindInとか気になる人向け
- ちなみにFor構文そのものはこのMonadContinuationsが頑張っているから出来ている感じですね(雑にしか読んでないけど)

完全なサンプル

DEV Community: 青年失業家 だねぴょん

そうだARROWを入れてみよう

結論

Option

例

reference

Either

例

reference

Try

例

reference

中間まとめ

ところどころドキュメント古い

他

疲れたので雑にいくつか

途中Eitherとかで包んでないんだけどよしなに包んで欲しい

rxjavaチックにThread切り替えたい

List<Option<Int>>みたいなのが、Option<List<Int>>にならないかな？

もっと強力な使い方無いの？？

終わり

Thanks Rx and Hello Arrow for Androider

まずは使ってみる

もうちょっと使ってみる

最後に

Reference

DEV Community: 青年失業家だねぴょん

`List<Option<Int>>`みたいなのが、`Option<List<Int>>`にならないかな？