uber-go / dig

A reflection based dependency injection toolkit for Go.
https://go.uber.org/dig
MIT License
3.78k stars 206 forks source link

dig.Container as a interface would be much easier to integrate #363

Closed shyandsy closed 1 year ago

shyandsy commented 1 year ago

if the dig.Container is an interface, its much easier to integrate, right?

type AppContext interface { 
    //GetContainer() *dig.Container 
    dig.Container
}

this we can use all function from dig.Container as methods in AppContext

sywhang commented 1 year ago

Yes, if it were an interface you'd be able to use all the methods directly on the AppContext.

Conceptually it wouldn't be completely out of question for Dig to expose an interface that would be implemented by both Scope and Container so that you could do something like that.

Changing Container to an interface is a breaking change. We follow semantic versioning rules and do not introduce any backwards-incompatible changes.

shyandsy commented 1 year ago

may be we can add a new way to use Dig as a interface

sywhang commented 1 year ago

My current thought on this is that we probably won't do this, as making an interface for this limits the extensibility of it.

If we decide to support additional methods on the Container struct, adding such a method is not a breaking change. Adding a method to an interface, however, is a breaking change.

Given the tradeoffs, I believe Dig's current structure of returning the struct is a better design choice for us to continue iterating on more features.

Hope that makes sense.