Skip to content

Commit

Permalink
Autowire limitations
Browse files Browse the repository at this point in the history
  • Loading branch information
adamw committed Sep 16, 2024
1 parent a0529b9 commit 730a38c
Showing 1 changed file with 11 additions and 0 deletions.
11 changes: 11 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,6 +44,7 @@ To use, add the following dependency:
- [Specifying implementations to use](#specifying-implementations-to-use)
- [Using dependencies contained in objects](#using-dependencies-contained-in-objects)
- [Errors](#errors)
- [Limitiations of autowire](#limitiations-of-autowire)
- [wire](#wire)
- [How wiring works](#how-wiring-works)
- [Factories](#factories)
Expand Down Expand Up @@ -212,6 +213,16 @@ autowire[UserStatusReader]()
// wiring path: UserStatusReader -> UserFinder -> DatabaseAccess
```

## Limitiations of autowire

`autowire` doesn't handle propagating generic type parameters, when creating missing dependencies using constructors or
`apply` methods. E.g. if you have a `class B[X](a: A[X])`, and a `B[Int]` needs to be created, the specific value for
the type parameter `X` won't be propagated when resolving the dependencies.

As a work-around, you need to explicitly provide the generic dependencies with concrete type parameters. A generic
dependency might appear multiple times, with different type parameters. To wire the classes from the example, you'd
need: `autowire[...](B[Int](_), someInstance: A[Int])` or similar.

# wire

![Scala 2](https://img.shields.io/badge/Scala%202-8A2BE2)
Expand Down

0 comments on commit 730a38c

Please sign in to comment.