Interface contract outside of the struct implementation

[ghazimuharam]

Hi everyone, thank you for introducing the new way of service implementation.

I'm trying to implement a POC for the service weaver and I stumbled upon this error internal/domain/reverser/reverser.go:16:6: weaver.Implements argument contract.Reverser is a type outside the current package.

The thing is, implementing the contract in a separate package could be a better solution, well at least for the implementation I'm tryna made.

I'm just wondering, is there any specific case of this rule that prevented the generator to use the interface contract outside of the implementation package?

// Implementation of the Reverser component.
type reverser struct {
	weaver.Implements[contract.Reverser]
}

[spetrovic77]

Thanks for reporting. Yes, we made a conscious decision not to support implementations of out-of-package interfaces, at least for now. @mwhittaker will have more state on this.

[mwhittaker]

Hi @ghazimuharam! Here's the code in weaver generate that disallows a struct from implementing a component interface outside its package:

https://github.com/ServiceWeaver/weaver/blob/35727ae307c392d27cadfbf5302d56a3e76977ab/internal/tool/generate/generator.go#L357-L360

As Srdjan said, this was a conscious decision. I don't remember exactly why we made this decision; it might have just been a simplifying assumption for our initial release. Let me think harder about whether there's any disadvantages to allowing a component implementation to be in a separate package from its component interface. If there's none, I can take a stab at relaxing the restriction!

[ghazimuharam]

Thank you, @spetrovic77 and @mwhittaker, for responding to my issue. As this appears to be a result of conscious decisions, I understand that I may need to wait for further clarification. However, please do not hesitate to reach out if you require any help from me. In the meantime, I will try to familiarize myself with the entire repository.

[jpearll]

Just to share that I've found the simple workaround to embed the external interface (from another package), to a local interface (same package) that is getting referenced by weaver.Implement. The code generation works fine.

[mwhittaker]

We explored the idea of allowing component interfaces and implementations to be in separate packages in #282 but ultimately decided to disallow it. In #285, we're updating an error message to suggest @jpearll's workaround.