Hi there! I've been a software engineer, techlead and lead architect. Now I'm a Software Director working at Openbank. Loving gaming and motorbikes. Writing software since I was 9. Since 1987 ;-)
The thing about sum | choice types is that the state machine around the status (in your example) is hard to design to allow parallel processing, i.e. when it's purely a linear flow, it's easy to model but when the domain grows and there are collaborators that alter part of the order either (pun intended) you need to redesign (which is not bad, after all needs and infra changed) or be extremely careful about where and how coupling happens.
Hi there! I've been a software engineer, techlead and lead architect. Now I'm a Software Director working at Openbank. Loving gaming and motorbikes. Writing software since I was 9. Since 1987 ;-)
BTW, the Validated approach, though nice, hides for me a fear for null. Since you are using kotlin, a validateEmail(email: String) would just return a ValidatedEmail (inline) or null.
Embrace null! Null is a valid domain idea! Check github.com/Kotlin/KEEP/blob/master...
At that link there are a lot of references about idiomatic kotlin being direct style instead of railway style (though doesn't forbid the 2nd!):
However, core Kotlin language and its Standard Library are designed around a direct programming style in mind.
I really like Kotlin nullable types because they force you to think about nullability and provides compile time checks against nullability.
I would use them maybe instead of data types like Option, because, as you said they are more idiomatic. I wouldn't go and use them in place of Eithers or Validated because they are currying other kinds of information and not simply the presence/absence of a value.
Well I have seen how difficult it is to work with a model that is in a 1:1 relation with its DB representation and I would say I would take my chances with choice types...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The thing about sum | choice types is that the state machine around the status (in your example) is hard to design to allow parallel processing, i.e. when it's purely a linear flow, it's easy to model but when the domain grows and there are collaborators that alter part of the order either (pun intended) you need to redesign (which is not bad, after all needs and infra changed) or be extremely careful about where and how coupling happens.
BTW, the Validated approach, though nice, hides for me a fear for null. Since you are using kotlin, a validateEmail(email: String) would just return a ValidatedEmail (inline) or null.
Embrace null! Null is a valid domain idea! Check github.com/Kotlin/KEEP/blob/master...
At that link there are a lot of references about idiomatic kotlin being
direct styleinstead of railway style (though doesn't forbid the 2nd!):I really like Kotlin nullable types because they force you to think about nullability and provides compile time checks against nullability.
I would use them maybe instead of data types like Option, because, as you said they are more idiomatic. I wouldn't go and use them in place of Eithers or Validated because they are currying other kinds of information and not simply the presence/absence of a value.
Well I have seen how difficult it is to work with a model that is in a 1:1 relation with its DB representation and I would say I would take my chances with choice types...