macwire
macwire copied to clipboard
Support parameters in wire[] to override dependencies
(One of the ideas from ScalaDays 2014 - by @matthewfarwell)
The wire[] method could accept parameters, which would be used to wire an instance of the given type; the parameters would take precedence over (override) vals/defs in wider scopes.
Example usage:
class Service(s2: Service2, s3: Service3, config: Map[String, String])
lazy val s2 = wire[Service2]
lazy val s3 = wire[Service3]
lazy val defaultConfig = Map("username" -> "default")
// here the given map would be used instead of the default
lazy val sA = wire[Service](Map("username" -> "admin"))
// here the default config map would be used and an alternative Service2 impl
lazy val sB = wire[Service](new Service2(...))
A parameter which doesn't match any of the constructor parameters of the wired type would result in a compile-time error.
This can be useful for:
- providing alternative implementations only for a single usage
- providing configuration values on a per-instance basis
+1 Make the error messages extra good on this one; could potentially be quite confusing sometimes (when ambiguous).
As a workaround, you can kind of trick Macwire to do this by making a factory then using it just once:
lazy val sA = {
def make(config: Map[String, String]): Service = wire[Service]
make(Map("username" -> "admin"))
}
That must be the first MacWire hack - nice ;)
Since #11 is implemented you can also do this:
lazy val sA = {
val config = Map("username" -> "admin")
wire[Service]
}
The advantage over wire[Service](Map("username" -> "admin")) is that you get to name your params.
Since #11 is implemented you can also do this:
lazy val sA = { val config = Map("username" -> "admin") wire[Service] }The advantage over
wire[Service](Map("username" -> "admin"))is that you get to name your params.
Can we add this method of solving ambiguity to the readme? In some cases it seems like a more practical approach than using Qualifiers
@k0rn1 please do, PR will be great :)