Implement wireResource for scala 2 by mbore · Pull Request #175 · softwaremill/macwire

mbore · 2021-08-27T14:00:35Z

No description provided.

adamw · 2021-10-11T15:06:05Z

One more naming idea: wireAuto in the package macwire.auto.cats?

mbore · 2021-10-11T18:48:09Z

@adamw actually in this case semiauto is more appropriate since we need to pass a list of available instances. Regarding the method name, I think that wireApp may be a good idea, because I'd like to make it work for instances wrapped in effects (e.g. IO[DatabaseAccess]) in future.

adamw · 2021-10-11T19:05:04Z

Hmm well but wireApp suggests that it's only for top-level applications, which is not true.

Another candidate: autowire, which is almost Spring ;) But you're right that semiAutoWire would be more correct, however it's longer and looks uglier in code ;)

adamw · 2021-10-11T19:05:20Z

And yes, sure, we do want to support instances wrapped in effects :)

adamw · 2021-10-11T19:48:10Z

Looks good :) There's a lot of tests to add, though. Maybe I'll just add them and then we'll have sth like TDD ;)

One thing that we'll need to decide is how to re-use instances. Right now we are re-using anything that is created by a resource - and this makes sense. When creating an instance of a class, do we want to re-use it? That is, should the following (assuming not only Resources are implemented):

case class A
case class B(a1: A, a2: A)

val b = wireX[B]

generate either (1):

val b = B(A(), A())

or (2):

val b = {
  val x = A()
  B(x, x)
}

Here it doesn't make a difference, but maybe for some cases it does make a difference whether a dependency is a singleton and re-used, or not.

Probably (1) is the better default, as it follows other DI frameworks where "dependent" scope is the default. And we could achieve singleton by explicitly passing in the instance. So I guess that's solved, or do you have another opinion? :)

adamw · 2021-10-14T19:12:57Z

  .dependsOn(macrosAkka, testUtil)
  .jvmPlatform(scalaVersions = scala2)

+  lazy val macrosCatsEffect = projectMatrix


I think I'd rename this to macrosAutoCats, and similarly, the package to .auto.cats. The current package name is way too long ;)

how about .auto.catssupport? .auto.cats clashes with the cats package

hm it conflicts, how? I guess import macwire.auto.cats._ or import macwire.auto.cats.autowire should work just fine? I've got a tapir.integ.cats package and as far as I know it works just fine ;)

We can come up with a different name, though ... however catssupport looks cumbersome. Maybe .autocats? ;)

adamw · 2021-10-14T19:13:52Z

+      !name.startsWith("java.lang.") && !name.startsWith("scala.")
+    }
+
+    def findeProvider(tpe: Type): Option[Tree] = findInstance(tpe)


[typo] -> findProvider

adamw · 2021-10-14T19:15:01Z

+In case you need to build an instance from some particular instances and factory methods it's recommended to use `autowire`. This feature is intended to interpolate with fp libraries (currently we support `cats`).
+
+`autowire` takes as an argument a list which may contain:
+* instances (e.g. `new A()`)


I think values would be more correct. Any value will do.

In fact ... do we have tests, that you can use a sub-type, where the dependency is of a super-type? E.g. I declare that I need a dependency of type trait A, but I provide a value of type class AA extends A. Same for resources etc.

For now we don't have tests for this case and we do not currently support it. I will add it to todo list

Maybe let's keep the todo as issues :) I've created #183 for this

adamw · 2021-10-14T19:16:46Z

+* factory methods (e.g. `C.create _`)
+* cats.effect.Resource (e.g. `cats.effect.Resource[IO].pure(new A())`)
+* cats.effect.IO (e.g. `cats.effect.IO.pure(new A())`)
+Based on the given list it creates a set of available instances and performs `wireRec` bypassing the instances search phase. The result of the wiring is always wrapped in `cats.effect.Resource`. For example:


what if multiple values for a given type are found? E.g. through a value and a resource? I think it should be an error

Currently it searches for instances, then resources, then effects. I agree that is should fail in such case, also it may be worth to check if all passed instances/resources/factory methods are used in the generated code.

I've created #181 & #182 to cover these

adamw · 2021-10-14T19:17:06Z

+
+  val theDatabaseAccess: Resource[IO, DatabaseAccess] = Resource.pure(new DatabaseAccess())
+
+  val theUserStatusReader: Resource[IO, UserStatusReader] = autowire[UserStatusReader](theDatabaseAccess)


❤️ this looks nice :)

mbore · 2021-10-15T06:03:52Z

Actually I'm still not sure if we want to support no parameters constructors.
It may cause difficult to debug mistakes like "forgot to pass filled config", for example:

import cats.effect._
import cats.effect.unsafe.implicits.global

class MutableConfig() {
  var port: Option[Int] = None
  var host: Option[String] = None
}

class Service(cfg: MutableConfig) {
  println(s"[${cfg.host}]:[${cfg.port}]")
}

object Main extends App {

  def loadConfig(): Resource[IO, MutableConfig] = Resource.pure {
    val mc = new MutableConfig()
    mc.host = Some("xyz")
    mc.port = Some(8080)

    mc
  }

  val cfg = loadConfig()

  val service = autowire[Service]()

  service.allocated.unsafeRunSync()._1

}

it works and prints [None]:[None].
I see that it may reduce boilerplate in some cases, but I'm not sure if it's worth to risk.

adamw · 2021-10-17T14:00:59Z

@mbore I've moved the no-arg constructor problem to #184 as well

mbore added 3 commits August 4, 2021 21:12

init work

87c4e2a

wire single resource

d414d7d

Add support for multiple resources

2ed2768

mbore mentioned this pull request Aug 27, 2021

Implement wireResource #173

Open

mbore added 3 commits August 29, 2021 20:15

add wireRec-like composition

c42f895

use default constructors & companion objects

5cc79d4

Refactor crimpers

f4ad58c

Fix test

9434160

Rename method

26bfca2

Apply CompanionCrimper changes

79f752c

Apply ConstructorCrimper changes

a038fb8

mbore marked this pull request as ready for review October 11, 2021 20:20

adamw added 5 commits October 12, 2021 10:49

Add some tests for wireApp

46b3835

Add assertions to tests, refactor tests

6a9888a

Add test for IOs

90b60e4

Add factory testsx

7e34d33

Failure tests with path

2b59d75

mbore commented Oct 12, 2021

View reviewed changes

Comment thread macrosCatsEffectTests/src/test/resources/test-cases/simpleMultiLevelProvidedParameter.success Outdated

Comment thread macrosCatsEffectTests/src/test/resources/test-cases/simpleMultiLevelNoParameters.success Outdated

mbore added 3 commits October 12, 2021 18:11

Move IO wrapped instances out of the scope for the current work

18cbd08

Add support for instances

1373434

Add basic support for factory methods

0d2d0d0

mbore force-pushed the simplified-wireResoure-scala2 branch from 6b43819 to ee50b16 Compare October 12, 2021 19:59

Add todo for resource factory method

42b5eea

mbore force-pushed the simplified-wireResoure-scala2 branch from ee50b16 to 42b5eea Compare October 12, 2021 20:10

Rename

0d797be

mbore added 3 commits October 14, 2021 08:41

Update readme

066f0a9

Add IO support

f190acd

Updated readme

e71c561

adamw reviewed Oct 14, 2021

View reviewed changes

mbore added 7 commits October 16, 2021 10:08

Fix typo

d08ddfc

change package name

cd9266a

Add subtype test case

5a04285

Updated readme

4e42834

Fix name

4232a19

Add support for subtyping

4b70ca2

Add tagging example

2bb2a00

mbore mentioned this pull request Oct 18, 2021

Tests for sub/super-types #183

Closed

change package name

53cdea2

mbore force-pushed the simplified-wireResoure-scala2 branch from 2bc32fb to 53cdea2 Compare October 21, 2021 16:15

Add subtype test for resource

0446fc3

adamw merged commit 5b0f8fc into master Oct 21, 2021

adamw deleted the simplified-wireResoure-scala2 branch September 10, 2024 10:12


		val theDatabaseAccess: Resource[IO, DatabaseAccess] = Resource.pure(new DatabaseAccess())

		val theUserStatusReader: Resource[IO, UserStatusReader] = autowire[UserStatusReader](theDatabaseAccess)

Conversation

mbore commented Aug 27, 2021

Uh oh!

adamw commented Oct 11, 2021

Uh oh!

mbore commented Oct 11, 2021

Uh oh!

adamw commented Oct 11, 2021

Uh oh!

adamw commented Oct 11, 2021

Uh oh!

adamw commented Oct 11, 2021

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mbore commented Oct 15, 2021

Uh oh!

adamw commented Oct 17, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants