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

Renames Either to Result #62

Merged
merged 1 commit into from Jan 11, 2017

Conversation

Projects
None yet
2 participants
@robotlolita
Member

robotlolita commented Jan 11, 2017

This pull request renames:

  • Either to Result;
  • Left to Error;
  • and Right to Ok.

Why?

The name Either, which is used by Haskell, is far more general then the name Result. However, because Either is biased — the Monad/Functor/etc instances only consider the Right case —, it ends up being used mostly as a way of modelling failures. Within this particular use case, the names Left and Right aren't particularly useful to help people figure out what they're supposed to be modelling.

Languages like Rust provide a Result type that has a vocabulary that's closer to the intention of the data structure. Meanwhile, languages like Scala don't provide a monad instance for its Either type, making it actually general-purpose.

The way Folktale does instances doesn't allow multiple instances to be defined, so we have to specialise the types anyway. And if we're doing that, it's better to use terms that are more useful for people who're trying to figure out what a particular piece of code does.

Breaking change

This is a breaking change from Folktale 1's data.either to Folktale 2, which won't have that data structure anymore. Users are encouraged to convert their code to use the new Result type, but they may use Data.Either and Folktale 2 until they convert all uses.

Converting from Data.Either to Folktale 2's Result involves:

  • Replacing the Data.Either library by the Folktale 2's Result:

    // BEFORE:
    const Either = require('data.either');
    
    // AFTER:
    const Result = require('folktale/data/result');
  • Replacing the Left constructor with Error, and the Right constructor with Ok:

    // BEFORE:
    Either.Left(someError);
    Either.Right(someValue);
    
    // AFTER:
    Result.Error(someError);
    Result.Ok(someValue);
  • Replacing instance tests by the new .hasInstance static method:

    // BEFORE:
    anEither.isLeft;
    anEither.isRight;
    
    // AFTER:
    Result.Error.hasInstance(aResult);
    Result.Ok.hasInstance(aResult);
  • Replacing .cata() with the new .matchWith():

    // BEFORE:
    anEither.cata({
      Left: (value) => ...,
      Right: (value) => ...
    });
    
    // AFTER (note the need to destructure):
    aResult.matchWith({
      Error: ({ value }) => ...,
      Ok: ({ value }) => ...
    });
(!! break) Renames Either to Result
BREAKING CHANGE: we're renaming the Either data structure to Result (as in Rust). Result just has a much better terminology, and our Either was a biased disjunction in any case.

Where one used to write:

    const { Left, Right } = require('folktale/data/either');

One would now write:

    const { Error, Ok } = require('folktale/data/result');

The data structure's name has been changed to Result. The `Left` case has been changed to `Error`, and the `Right` case has been changed to `Ok`. This affects all uses of `.matchWith` as well as constructing values.

@robotlolita robotlolita added this to the v2.0.0 milestone Jan 11, 2017

@robotlolita robotlolita merged commit 96f4558 into master Jan 11, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@robotlolita robotlolita deleted the patch/either-to-result branch Jan 11, 2017

@minipai

This comment has been minimized.

Show comment
Hide comment
@minipai

minipai Aug 9, 2018

@robotlolita
The Why? should be in the migration doc! 👍
I have been wondering and looking for it for a while.
Learned a lot from it and I thinks it's very valuable, it's a shame to be buried in PR.

minipai commented Aug 9, 2018

@robotlolita
The Why? should be in the migration doc! 👍
I have been wondering and looking for it for a while.
Learned a lot from it and I thinks it's very valuable, it's a shame to be buried in PR.

@robotlolita

This comment has been minimized.

Show comment
Hide comment
@minipai

This comment has been minimized.

Show comment
Hide comment
@minipai

minipai Aug 15, 2018

Cooool 🎉 🎉

minipai commented Aug 15, 2018

Cooool 🎉 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment