Remove wiring from `def` or add `@NotForWiring`

Open
#77 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
scala
Domain
backend

Research direction

Start at the wire[A] entry point and trace how eligible vals and defs are discovered, including parameterized methods. Review the proposed alternatives in the issue and determine how the selected behavior should handle newFrozenClock and the ambiguous clock dependency. Done means parameterized methods are not incorrectly invoked and the demonstrated wiring case is unambiguous.

Written by the indexing model from the issue text.

Description

Currently we have this problem:

case class A()
case class B(a: A)

object Test {
    lazy val a: A = wire[A]
    def buildSomeA(i: Int): A = A()
    lazy val b: B = wire[B] // without `val a`, macwire would produce this: `A(buildSomeA)`...
}

Fails with: Found multiple values of type [A]: [List(buildSomeA, a)]

So 2 things:

  • first methods with args are found eligible and they are used without any args (thus producing a compilation error),
  • second we quickly end-up with ambiguities

I have the following use case:

class Stuff(clock: Clock)

trait TestBase {
  lazy val clock: Clock = Time
  def newFrozenClock: Clock
}

class StuffTest extends TestBase {
   @Test def doStuff() { wire[Stuff] } // clock is ambiguous
}

So either we ditch def "support" (I know you've been using it as a "prototype" scope) or we keep it (modulo a little bugfix for parameterized methods) and we introduce another annotation: @NotForWiring. That way things can be disambiguated once for all:

trait TestBase {
  lazy val clock: Clock = Time
  @NotForWiring def newFrozenClock: Clock
}
Dominant language
Scala
Stars
1.3k
Forks
77
Avg merge
9m
Merged PRs (30d)
4

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from softwaremill/macwire

All issues in softwaremill/macwire

Similar issues

More Scala issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.