Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make documentation more usable #219

Open
luksow opened this issue Jan 3, 2024 · 1 comment
Open

Make documentation more usable #219

luksow opened this issue Jan 3, 2024 · 1 comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed

Comments

@luksow
Copy link
Contributor

luksow commented Jan 3, 2024

Current documentation lives under: https://theiterators.github.io/sealed-monad/ and is very limited. Ideally it should:

  • show case some beautiful code example on the intro page,
  • tell more about ADT-centric error handling,
  • show more use cases,
  • main GH page (https://github.com/theiterators/sealed-monad) could feature more details from the docs,
  • travis badge doesn't work anymore,
  • logo should be updated.
@luksow luksow added help wanted Extra attention is needed good first issue Good for newcomers labels Jan 3, 2024
@MateuszKubuszok
Copy link

MateuszKubuszok commented Jan 4, 2024

Things that were most surprising initially to me, which I would highlight:

  • there are 2 type params that describe some result type: Sealed[F, A, ADT] - A and ADT

    • A is an intermediate result type of sort
    • ADT is like a final result type
  • ADT is used for handling errors, HOWEVER it is also used as a final result type when exiting the Sealed monad in run - therefore while most of the time ADT can be used for some error-only type, on run ADT is expected to be something which stores both errors and success values

  • in a way it makes it similar to (a: L).tailRecM[R](... : L => F[Either[L, R]])'s parameters where L is intermediate result and R is final result

  • however when we are thinking that Sealed is similar to EitherT then we might be surprised because EitherT[F, L, R] flatMaps/maps etc on right R value, while Sealed[F, A, ADT] on left A value

    • to add to confusion method names are borrowed from EitherT
  • probably it would make more sense to use examples comparing it to Result<S, F> from Rust which has a success as the first and a failure as the second type parameter

  • it would also make sense to show that intended usages for ADT is something like

    enum UserCreationResult:
      case Success
      case UserAlreadyExists(details: String)
      case InvalidEmail(details: String)

    which models all allowed outcomes for some business action

    • since such enums are sealed traits in Scala 2 it explains the Sealed name, but I haven't been able to make that connection for a long time

All in all use cases are pretty reasonable BUT do not match Cats conventions and without a proper explanation Cats' users might follow wrong intuitions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants