Extend cats-autowire to handle any effect type

[adamw]

Currently autowire works only for IO. It would be great if it would:

(a) work for any F[_]
(b) verify (if at all possible?) that all passed effects/factories/resources use the same effect type - or rather, that they can be parametrised with the same effect type

[mbore]

The next step may be to verify if it is possible to add support for other return types like ZManaged or an effect that meets some requirements

[adamw]

Supporting ZManaged is a different task - adding a parallel implementation (hopefully sharing some code) for zio. Here it's about supporting code parametrised with the effect type, so if the user provides Resource[F] for some F[_], and where we need to return Resource[F] as well.

[adamw]

See #190 for zio support

[mbore]

ok, makes sense. It would be also good to create a pure autowire implementation. #191

[djx314]

In scala 2, in fact it's a problem like cps.

https://github.com/ThoughtWorksInc/dsl-domains-cats

In scala 3, it's a problem like cats-effect-cps.

https://github.com/typelevel/cats-effect-cps

I wrote a repo use these to implement wire.

https://github.com/scalax/ce-injection-samples

But it's not what I want. I wrote some suggestion in gitter. I hope it can have some helpful.

[djx314]

I think just use target effect type to support F[_] will be some difficulties.
Wrap a case class like fs2 I think is more "type friendly". Just

// case class[F[_], T](model: F[T])

And provide a simple Monad[IO] with any target effect type, we can simple find the target class which need to inject it's constructor.
And as the suggestion in gitter, displays the parameter need in building the constructor injection will broken something about "injection by type".
So I think separate effect type and model type can provide a frindly ”type environment“ to solve this problem.

[djx314]

Just have a test and will bring back some freeback.
Sorry for read the code with some misconceptions since I have implemented it in a way with the less correlation.

[djx314]

@adamw I think injection without F[_] can simply create a model like

// sealed trait Injection
// case class FunctionInjection(val func: Any => Injection, val input: Injection]) extends Injection
// case class ModelInjection(val value: Any) extends Injection

And we can tag this to F[_]. like

// sealed trait Injection
// case class FunctionInjection(val func: Any => Injection, val input: Injection) extends Injection
// case class EffectInjection(val effectValue: F[Injection]) extends Injection
// case class ModelInjection(val value: Any) extends Injection

I plan to use implicit to implement a injection since implicit in scala 2 means context so in scala 3 it calls context abstraction. So the code that in my thinking is something like the injection without cats-effect in macwire.

[djx314]

In the abstraction of Injection with F[_], we can no use to do something like close, release because Resource and many many things will do this for us. It seems that many things in Spring's Injection now just leave it to F[_]

[djx314]

Yes, like ZManaged[A & B, Nothing, C], we just print it as

// val a: Injection = implement ZManaged[X, X, A]
// val b: Injection = implement ZManaged[X, X, B]
// val c: Injection = FunctionInjection(func = need => genInjectionC, input = List(a, b))

and we just tag the info in the case class what your ast need. And than we can simply singed it ZManaged[A & B, Nothing, C] just we won't implement this injection dependent on the type in fact.

[djx314]

tough the email since changing the code above.

[adamw]

Hm, interesting idea - so autowire would generate a description, of how the injection should be done. And then at run-time, we can pick the appropriate effect.