Alias Dry::Monads::Result as Dry::Operation::Result

[cllns]

Overview

This change would completely abstract away the implementation detail of using dry-monads. Monads are often intimidating to Ruby programmers, so it'd be nice if we could hide it from them. Then we can position dry-operation as a thin API and "just pattern matching" on the result, instead of thinking they need to understand what a monad before using it.

My primary interest here is for Hanami 2.2 users, who will get dry-operation included in their apps. A reference here is from Evan Czaplicki's talk "Let's be mainstream!" where he talks about avoiding using "monad" at all, which is what Elm does.

Details

Instead of Dry::Monads[:result], users will include Dry::Operation::Result::Mixin. Since we're just aliasing the constant, people can include the result from Dry::Monads and it'll work as desired. This might be nice if people are including several monads.

We could change this to something like Dry::Operation[:result] if we want to extend this, but I just wanted to open this PR to get the conversation started.

Tradeoff

This does add some indirection, since we're adding an alias. I think it's worth it since it lowers the bar to entry for new users of dry-monads, and it only adds a small amount of added complexity for people working on dry-operation.

[waiting-for-dev]

Hey @cllns, sorry for not getting back sooner in the original conversation. TBH I'm not 100% on board here. While I share your concerns about using THAT word (😉 ) as I said in the discussion I think the way to go should be creating different adapters for different kinds of result types. Also, in the context of hanami & dry-rb, it probably doesn't make sense to hide what we're actually using. As I said, ideally I'd like to rename dry-monads to something else, but 🤷

[timriley]

I'm happy for us to take a wait and see approach here. Let's keep dry-operation largely unadorned for its first release, and learn from real usage about where we should extend or streamline it.

@cllns Thanks for raising this though, I think it prompted some valuable discussions!

@waiting-for-dev I'm interested for your thoughts on alternative names for dry-monads ;)

[waiting-for-dev]

@waiting-for-dev I'm interested for your thoughts on alternative names for dry-monads ;)

Not that I have a definitive alternative, @timriley 🙂 dry-result would work for something like the Maybe & Result types. However, it would look off for something like List.