You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we use only constructor injection, no dependency to DI itself is necessary other than the design part
No need to worry about which injection to use (in-trait or constructor?). It will also reduce the learning cost. Half of the current documentation (https://wvlet.org/airframe/docs/airframe) will be unnecessary.
Deprecate in-trait bindings
For supporting Scala 3 at ease. Writing macros for nested trait instantiation is the tricky part. If we use constructor injection, the code will be much simpler
Migration plan
Retain the current airframe module as is.
Add a new module "airframe-di" so that the user can migrate to a new one at any timing.
The package name will be wvlet.airframe.di => Deprecate in-trait injection only from Scala 3! Use the same package name to reduce the confusion.
Usage stats of in-trait bindings (inside TD)
bind[X] a lot!!!
bindLocal[X] only a few times
bindFactory[X] only a few times
So dropping bindLocal, bindFactory should be ok.
The text was updated successfully, but these errors were encountered:
Support only constructor injection!
Deprecate in-trait bindings
Migration plan
The package name will be=> Deprecate in-trait injection only from Scala 3! Use the same package name to reduce the confusion.wvlet.airframe.di
Usage stats of in-trait bindings (inside TD)
The text was updated successfully, but these errors were encountered: