• package root
    Definition Classes
  • package izumi
    Definition Classes
  • package functional
    Definition Classes
  • package bio

    Current hierarchy (use to render, rendered:

    Current hierarchy (use to render, rendered:


    Auxiliary algebras:


    Raw inheritance hierarchy:


    current hierarchy roots:


    • Functor3
    • Bifunctor3
    • Parallel3
    • Temporal3


    • Fork3
    • BlockingIO3
    • Primitives3
    • PrimitivesM3
    Definition Classes
  • package lifecycle
    Definition Classes
  • Lifecycle
  • LifecycleAggregator
  • package quasi
    Definition Classes

package lifecycle

Linear Supertypes
AnyRef, Any
  1. Alphabetic
  2. By Inheritance
  1. lifecycle
  2. AnyRef
  3. Any
  1. Hide All
  2. Show All
  1. Public
  2. Protected

Type Members

  1. trait Lifecycle[+F[_], +A] extends AnyRef

    Lifecycle is a class that describes the effectful allocation of a resource and its finalizer.

    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] =
        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, scoped zio.ZIO or a zio.managed.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 {

    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:

    See also




    scoped zio.ZIO


  2. type Lifecycle2[+F[+_, +_], +E, +A] = Lifecycle[[β$0$]F[E, β$0$], A]
  3. type Lifecycle3[+F[-_, +_, +_], -R, +E, +A] = Lifecycle[[γ$1$]F[R, E, γ$1$], A]
  4. final class LifecycleAggregator[F[+_, +_], E] extends AnyRef

Value Members

  1. object Lifecycle extends LifecycleInstances
  2. object LifecycleAggregator

Inherited from AnyRef

Inherited from Any