Cross posting here, in case anyone has some advice...
# codingconventions
v
Cross posting here, in case anyone has some advice: https://kotlinlang.slack.com/archives/C1H43FDRB/p1683656637745809
y
What you can just do is have
Success
exist standalone as a sealed interface, and then use the normal
Result
class, and deal with the different types of success using a
when
on the actual value inside of the Result (because what's the point of treating a failure as a
Result<SuccessType1>
Vs a
Result<SuccessType2>
)
v
The success type is predetermined on invocation though. So doing the when on the success types would be redundant -- both from the compiler's pov but also from the coder's pov
y
As in you get a
Result<SuccessType1>
instead of a more general
Result<Success>
?
v
Yep, exactly. There would be a handful of different successes in the grand scheme of the codebase, but when it's being used the result will be only be a Failure or a specific Success
The reason for wanting to code it up like this is 2-fold: 1. To reduce repetition (i.e. not create a Result type for each Success type) 2. To prevent having to unwrap in the case where I go with a wrapper Success data class (i.e.
(result as Success).value.someProperty
) I'm leaning towards approach 2 though if my original approach using sealed classes doesn't work
y
Do you really even need a sealed hierarchy then? Just use the real values for success. You won't need to create new result types cuz you'll just use the stdlib one, and you won't need to unwrap further (because you can go with the most basic hierarchy datatype, and you'll just get the value out of (kotlin's)
Result
with no further wrappers
v
One more constraint on that note -- I also want the Result class to implement Android's
Parcelable
y
Hmmmm, you could use something like Arrow's
Either
, or if you really want the
value class
performance, then just copy the Result source code and make it additionally parcelable (although note that that will box)