Bruno Bieth
Bruno Bieth
Thanks @ebowman, any idea if this is being considered?
This feature can be disabled with the `interactiveCommit` attribute
Since #11 is implemented you can also do this: ``` scala lazy val sA = { val config = Map("username" -> "admin") wire[Service] } ``` The advantage over `wire[Service](Map("username" ->...
Ok, then you'd go for 2). So again you should really consider having a single place for macwire documentation and remove everything that's macwire specific from di-in-scala. You make no...
I figured you can workaround the absence of `@NotForWiring` by exploiting the lack of support of `protected` members (everything that's not public is ineligible): ``` scala trait TestBase { lazy...
`@NotForWiring` could also be added to types so that: ``` scala @NotForWiring trait MyMatchers { def matcher1: Matcher[Stuff1] = _ def matcher2: Matcher[Stuff2] = _ } class MyTest extends MyMatchers...
This should also prove useful when you want to expose some of the inner parts of your object for testing: ``` scala package complex // primary constructor is package private...
Yep, secondary constructors could be evaluated too - as long as they are unique, as you said.
`TypeApi.companion` does not seem to work? I've asked on scala-user (https://gitter.im/scala/scala/scala-user?at=55f6b30c8cc5f90a4fb6bf55) but so far no answer...
Note about runtime dependencies: let's suppose that we move `Tagging` away from the macros (#49), and you decide to go for the JSR-330 annotation style, then you could just limit...