Add method forwarders to `Resource`

[djspiewak]

Resource implements Async, but does so in a purely "typeclassy" way. If you want to do something like rsrc.start (where rsrc: Resource[F, A]), you actually need to import cats.effect.syntax.all._! This isn't a great experience.

Instead, we should flip all of this around and follow the same pattern IO does: move the definitions of these methods to Resource itself as members (taking the appropriate implicit evidence for F individually), and then change the typeclass implementations to simply forward the call onto the appropriate member function. This is actually a pretty easy change, just a little tedious and time-consuming. It should help with the ergonomics quite considerably though.

[alexandrustana]

I could try and tackle this one

[joroKr21]

Would that also include relaxing the constraints for each method?

[djspiewak]

Would that also include relaxing the constraints for each method?

Potentially yes. Do you have an example in mind?

[joroKr21]

Potentially yes. Do you have an example in mind?

I think there are a few examples (there might be others):

constraint	methods
Unique	unique
GenSpawn	never, cede
ApplicativeError	attempt, handleErrorWith, raiseError

[alexandrustana]

Just to be sure I'm going in the right direction 😅
Basically, I just have to add the methods provided by the typeclasses which Resource has implementations for.
Such as:

• Semigroup, Monoid, Monad, MonadError, MonadCancel, Clock, Concurrent, Sync, Temporal, SemigroupK and Async

e.g.

def startOn(ec: ExecutionContext)(
      implicit F:   Async[Resource[F, *]]
    ): Resource[F, Fiber[Resource[F, *], Throwable, A @uncheckedVariance]] = F.startOn(x, ec)

Right?

P.S. Sorry this question comes so late, should have done this investigation beforehand.

[vasilmkd]

No worries! We're mostly interested in the methods that originate in the Cats Effect typeclasses.

I'd follow IO.scala and replicate all methods that are not currently available on Resource that make sense. I don't have a concrete list, but I'm sure you can figure it out and we'll review it. Hope this helps.

[joroKr21]

I thought the idea was to move the implementations themselves and forward to them from the type class like this:

trait Resource:
  def startOn(ec: ExecutionContext)(implicit F: Async[F]): Resource[F, Fiber[Resource[F, *], Throwable, A]] = ???
    // move implementation here

object Resource:
  implicit def asyncInstance[F[_]](implicit F: Async[F]) = new Async[Resource[F, *]] {
    def startOn[A](fa: Resource[F, A])(ec: ExecutionContext): Resource[F, Fiber[Resource[F, *], Throwable, A]] =
      fa.startOn(ec)

[vasilmkd]

That's also a part of this, yes. Thanks @joroKr21

[djspiewak]

I thought the idea was to move the implementations themselves and forward to them from the type class like this:

You're basically both right. :-) So any implementation which is Resource-specific (such as start) should be moved out of the typeclass and into Resource itself, and then the typeclass should forward to Resource as in @joroKr21's example. However, plenty of combinators (such as startOn) are implemented in a generic way higher up in the hierarchy, and those could be delegated from Resource to the typeclass.

Basically the way that IO is doing things is the right pattern to follow. :-)

[alexandrustana]

@joroKr21 @vasilmkd @djspiewak thank you for answering my question and for the examples.
I think I got the gist of it 😅