vavr zwracanie wyniku

Cześć, chce zrobić funkcje, która w zależności od tego czy po drodze spotkała błąd zwraca wiadomość z błędem lub wynik.

fun doSomething(args: Array<String>): Result {
    val parsed = this.parseArgs(args) // zwraca mape wypełnioną Either<String, Any> String wiadomość z błędem, Any to wynik
    // jesli cos zwrociło błąd (lewą strone Either) zwraca Result.Error(error)
}

czy to sensowne rozwiązanie problemu?

fun doSomething(args: Array<String>): Result {
    val parsed = this.parseArgs(args) 
    val errors = parsed.values.filter { it.isLeft }.map { it.left }

    if (errors.isNotEmpty()) {
        return Result.Error(errors[0])
    }

    // do magic
    return Result.Success
}

Nie wiem dokładnie co chcesz osiągnąć ale eithery możesz sprasować do jednego

 Either
                    .sequence(parsed.values) //otrzymujesz tu Either<List,List> teraz pytanie co chcesz z tym dalej zrobić
                    .mapLeft(Traversable::head) //jeśli tylko pierwszy bład
                    .map(Result.Success) // w zależności co chcesz zwrócić

@tomek232: od tego jest funkcja getOrElseGet

danek napisał(a):

Nie wiem dokładnie co chcesz osiągnąć ale eithery możesz sprasować do jednego

 Either
                    .sequence(parsed.values) //otrzymujesz tu Either<List,List> teraz pytanie co chcesz z tym dalej zrobić
                    .mapLeft(Traversable::head) //jeśli tylko pierwszy bład
                    .map(Result.Success) // w zależności co chcesz zwrócić

Przemyślałem to i teoretycznie nie potrzebuje nawet zwracać Result.Success. Mogę zakładać, że jeśli nie zwróciło blędu to operacja się udała, tą drogą doszedłem, że moge zwracać Option<String>.

        val parsed = this.parseArgs(args)

        return Either
                .sequence(parsed.values)
                .mapLeft { it.headOption() }
                .left
                .onEmpty { this.call(parsed) } 

A co ta funkcja ma robić i co ma zwracać?

Cała funkcja zwraca błąd zapakowany w optionala, jeśli nie wystapił żaden błąd optional będzie pusty, co informuje mnie o tym, że wszystko wykonało się poprawnie. A call wykonuje całą magią, nie zwraca nic, wykonuje tylko na funkcji callBy.
Dzięki za pomoc.

Jestem bardzo ciekawy jak ten kawałek kodu wyglądałby bez użycia Vavra :)

Charles_Ray napisał(a):

Jestem bardzo ciekawy jak ten kawałek kodu wyglądałby bez użycia Vavra :)

Pewnie jakoś tak

    fun test(args: Array<String>): FunctionResult {
        val parsed = try {
            this.parseArgs(args)
        } catch (e: Exception) {
            return FunctionResult.Error(e.cause.message)
        }
        
        this.call(parsed)
        return FunctionResult.Success
    }

Charles_Ray napisał(a):

Dziękuje. To ja poproszę taka opcje w IntelliJ jak „unvavr"

Bo Vavr w pojedynczej funkcji wcale nie musi sprawiać, że coś będzie bardziej czytelne. Dopiero stosowanie określonych konwencji w całym projekcie może pokazać jak Either czy Option czy cokolwiek innego potrafi ułatwić "czytanie" kodu, a w szczególności sygnatur. Inna sprawa, to to, że można olać te całe Eithery czy Optiony Vavrowe, byleby używać niemutowanych kolekcji które są tam podefiniowane - to jest prawdziwe uproszczenie kodu które jest widoczne ;)

@Charles_Ray: czuje sie troche rozczarowany Twoimi postami o Vavrze :P To jest bardzo dobra biblioteka tylko jej zalet nie widać przy 3 linijkach. Tu trzeba troche zmienić podejście do tego np. co jest wyjątkiem a co jest przewidywalnym rezultatem, docenić zalety niemutowalności itp.
Ja sądze że miks FP i OOP pozwala na pisanie dużej jakości kodu, bo FP świetnie nadaje się do przetwarzania danych a OOP do enkapsulacji i side efektów. Niestety wielu programistów dąży do dwóch skrajności, albo nie chcą poznawać nowych paradygmadów i podejścia do architektury albo kierują sie hypem...