izumi.functional.lifecycle

Members list

Concise view

Type members

Classlikes

trait Lifecycle[+F[_], +OuterResource]

Lifecycle is a class that describes the effectful allocation of a resource and its finalizer. This can be used to represent expensive resources.

Lifecycle is a class that describes the effectful allocation of a resource and its finalizer. This can be used to represent expensive resources.

Resources can be created using Lifecycle.make:

 def open(file: File): Lifecycle[IO, BufferedReader] =
   Lifecycle.make(
     acquire = IO { new BufferedReader(new FileReader(file)) }
   )(release = reader => IO { reader.close() })

Using inheritance from Lifecycle.Basic:

 final class BufferedReaderResource(
   file: File
 ) extends Lifecycle.Basic[IO, BufferedReader] {
   def acquire: IO[BufferedReader] = IO { new BufferedReader(new FileReader(file)) }
   def release(reader: BufferedReader): IO[BufferedReader] = IO { reader.close() }
 }

Using constructor-based inheritance from Lifecycle.Make, Lifecycle.LiftF, etc:

 final class BufferedReaderResource(
   file: File
 ) extends Lifecycle.Make[IO, BufferedReader](
   acquire = IO { new BufferedReader(new FileReader(file)) },
   release = reader => IO { reader.close() },
 )

Or by converting from an existing cats.effect.Resource or a zio.ZManaged:

Usage is done via use:

 open(file1).use {
   reader1 =>
     open(file2).use {
       reader2 =>
         readFiles(reader1, reader2)
     }
 }

Lifecycles can be combined into larger Lifecycles via Lifecycle#flatMap (and the associated for-comprehension syntax):

val res: Lifecycle[IO, (BufferedReader, BufferedReader)] = {
  for {
    reader1 <- open(file1)
    reader2 <- open(file2)
  } yield (reader1, reader2)
}

Nested resources are released in reverse order of acquisition. Outer resources are released even if an inner use or release fails.

Lifecycle can be used without an effect-type with Lifecycle.Simple it can also mimic Java's initialization-after-construction with Lifecycle.Mutable

Use Lifecycle's to specify lifecycles of objects injected into the object graph.

 import distage.{Lifecycle, ModuleDef, Injector}
 import cats.effect.IO

 class DBConnection
 class MessageQueueConnection

 val dbResource = Lifecycle.make(IO { println("Connecting to DB!"); new DBConnection })(_ => IO(println("Disconnecting DB")))
 val mqResource = Lifecycle.make(IO { println("Connecting to Message Queue!"); new MessageQueueConnection })(_ => IO(println("Disconnecting Message Queue")))

 class MyApp(db: DBConnection, mq: MessageQueueConnection) {
   val run = IO(println("Hello World!"))
 }

 val module = new ModuleDef {
   make[DBConnection].fromResource(dbResource)
   make[MessageQueueConnection].fromResource(mqResource)
   make[MyApp]
 }

 Injector[IO]()
   .produceGet[MyApp](module)
   .use(_.run())
   .unsafeRunSync()

Will produce the following output:

 Connecting to DB!
 Connecting to Message Queue!
 Hello World!
 Disconnecting Message Queue
 Disconnecting DB

The lifecycle of the entire object graph is itself expressed with Lifecycle, you can control it by controlling the scope of .use or by manually invoking Lifecycle#acquire and Lifecycle#release.

== Inheritance helpers ==

The following helpers allow defining Lifecycle sub-classes using expression-like syntax:

The main reason to employ them is to workaround a limitation in Scala 2's eta-expansion — when converting a method to a function value, Scala always tries to fulfill implicit parameters eagerly instead of making them parameters of the function value, this limitation makes it harder to inject implicits using distage.

However, when using distage's type-based syntax: make[A].fromResource[A.Resource[F]] — this limitation does not apply and implicits inject successfully.

So to workaround the limitation you can convert an expression based resource-constructor such as:

 import distage.Lifecycle, cats.Monad

 class A
 object A {
   def resource[F[_]](implicit F: Monad[F]): Lifecycle[F, A] = Lifecycle.pure(new A)
 }

Into a class-based form:

 import distage.Lifecycle, cats.Monad

 class A
 object A {
   final class Resource[F[_]](implicit F: Monad[F])
     extends Lifecycle.Of(
       Lifecycle.pure(new A)
     )
 }

And inject successfully using make[A].fromResource[A.Resource[F]] syntax of izumi.distage.model.definition.dsl.ModuleDefDSL.

The following helpers ease defining Lifecycle sub-classes using traditional inheritance where acquire/release parts are defined as methods:

Attributes

See also:

ModuleDef.fromResource

Companion:
object
Graph
Supertypes
class Object
trait Matchable
class Any
Known subtypes
trait Basic[F, A]
class Make[F, A]
class Make_[F, A]
class NoClose[F, A]
trait Simple[A]
trait FromCats[F, A]
trait FromPair[F, A]
class MakePair[F, A]
trait FromZIO[R, E, A]
class NoCloseBase[F, A]
class LiftF[F, A]
class SelfNoClose[F, A]
trait OfInner[F, A]
class Of[F, A]
class FromAutoCloseable[F, A]
class OfCats[F, A]
class OfZIO[R, E, A]
trait Self[F, A]
trait Mutable[A]
trait SelfOf[F, A]
trait MutableOf[A]
object Lifecycle

Attributes

Companion:
trait
Graph
Supertypes
class Object
trait Matchable
class Any
Self type
final class LifecycleAggregator[F[_, _], E](finalizers: RefM2[F, List[(Key, F[E, Unit])]])

Attributes

Companion:
object
Graph
Supertypes
class Object
trait Matchable
class Any

Attributes

Companion:
class
Graph
Supertypes
class Object
trait Matchable
class Any
Self type

Types

type Lifecycle2[+F[_, _], +E, +A] = Lifecycle[[_] =>> F[E, _$3], A]
type Lifecycle3[+F[_, _, _], -R, +E, +A] = Lifecycle[[_] =>> F[R, E, _$7], A]