Specify module for method parameter types to avoid ambiguity

[wvteijlingen-npo]

Our codebase has multiple modules that contain types with the same name, for example: ModuleA.Foo and ModuleB.Foo. The generated mock file will import both ModuleA and ModuleB, leading to ambiguity for the Foo type.

Would it be possible to always specify the module, thereby resolving any ambiguity?

Example

Input

// ModuleA

public struct Foo {}

public protocol ProtocolInModuleA {
  func doSomething(with: Foo) -> Void
}

// ModuleB

public struct Foo {}

Current mocks

// Mocks.generated.swift

import ModuleA
import ModuleB

class ProtocolInModuleAMock {
    // These references to Foo are ambiguous
    var doSomethingArgValues = [Foo]()
    var doSomethingHandler: ((Foo) -> ())?
    func doSomething(with: Foo) { ... }
}

Expected mocks

// Mocks.generated.swift

import ModuleA
import ModuleB

class ProtocolInModuleAMock {
    // These references to Foo are explicitly disambiguated by including the module
    var doSomethingArgValues = [ModuleA.Foo]()
    var doSomethingHandler: ((ModuleA.Foo) -> ())?
    func doSomething(with: ModuleA.Foo) { ... }
}

[sidepelican]

This is interesting.
Since mockolo does not know the origin of the types that appear in the protocol definition, assuming that Foo implicitly refers to ModuleA's version would likely cause other issues.
For now, manually specifying the priority as shown below can resolve the problem:

// in the same target with Mocks.generated.swift
import ModuleA
typealias Foo = ModuleA.Foo

To solve this issue correctly in an automated way, an approach like #105 might be necessary.
If the mock implementation file imports the same modules as the original file, you wouldn’t need to import ModuleB, which should prevent the problem.

[wvteijlingen-npo]

The workaround using typealias works for now, too bad that it requires manual changing of the file every time the mocks are regenerated.

Since mockolo does not know the origin of the types that appear in the protocol definition

I see, that is unfortunate. Would it be possible to extend Mockolo in such a way that it obtains enough information about the types to enable module prefixing? Or would that be waay out of scope for the project?

[sidepelican]

You don't need to manually update every time—just place a file with a typealias next to the generated file.

Deep type analysis is outside the scope of mockolo.

[wvteijlingen-npo]

You don't need to manually update every time—just place a file with a typealias next to the generated file.

Of course! Thanks for the tip 👍