Allow to specify an interface when providing a constructor

[alessandrozucca]

Update (by @glibsm)

The addition of dig.As ProvideOption has been agreed on.

---

Currently dig only uses a constructors that returns exactly what the function expects.

If the function accepts an interface, and we don't inject the constructor that returns that interface we get this error

panic: missing dependencies for function "main".main.func1 (..../main.go:29): type main.Fooer is not in the container, did you mean to use *main.Foo?

Take the following example

type Foo struct{}

func NewFoo() *Foo {
	return &Foo{}
}

func (b *Foo) Hello() {
	fmt.Println("hello")
}

type Fooer interface {
	Hello()
}

func main() {
	di := dig.New()
	err := di.Provide(NewFoo)
	if err != nil {
		panic(err)
	}
	err = di.Invoke(func(f Fooer) {
		fmt.Printf("f: %+v", f)
	})
	if err != nil {
		panic(err)
	}
}

So to make it work it needs to have a constructor function such as:

func NewFoo() Fooer {
	return &Foo{}
}

which is basically making us declare that Foo implements Fooer
Would it be feasible to change the library so that it can workout itself if the struct implements the interface? [edit] as clarified in the comments this suggestion won't work

Or alternatively, add a new ProvideOption which allow us to specify which concrete implementation to inject for a given interface?

[abhinav]

Hello! This is a good question and a recurring problem.

Although it's possible for dig to map structs to interfaces, we explicitly
chose not to do this because of the ambiguity it introduces. Without
explicitly saying "Use Foo for Fooer", you can have a situation where another
object just happens to implement Fooer, but you don't want it to be used as
such in your application. You end up with no guarantee that the correct object
will be picked, and there's no good way to say "Use only this object as Fooer"
outside of what you already have to do with dig.

That said, this is still something we would like to simplify in the future. A
clean API for doing so hasn't presented itself yet and finding one hasn't been
a priority for us because the current approach is only a little inconvenient.

We'll keep an eye out for a design that solves this well, but until then the
extra little boilerplate isn't too much to deal with.

---

A ProvideOption that allows you to specify the concrete implementation would
be more boilerplate than func(f *Foo) Fooer { return f } because Go doesn't
have a syntax to reference types as objects. What I mean is, you can't do,

UseImplementation(*Foo)
UseImplementation(Foo)

You'd have to provide the type information through another concrete type that
you can pass around like a func, a value, or a pointer.

UseImplementation(func() *Foo {})
UseImplementation(Foo{})
UseImplementation((*Foo)(nil))

IMO that's more confusing than just,

func(f *Foo) Fooer { return f }

[alessandrozucca]

Hi @abhinav

They are both valid points so i'll just keep doing something along the lines of providing func(f *Foo) Fooer { return f }

Thanks for the clarification and open sourcing this library

I'll close the issue

[abhinav]

Re-opening because another possible API came up. We can pass references to
interfaces in a more readable way with new(Fooer) so we can probably do
something along the lines of,

func NewFoo() *Foo

c.Provide(NewFoo, dig.Cast(new(Fooer)))

We'll want to figure out naming to make it explicit that this isn't an
arbitrary cast, only interfaces. Maybe dig.As(...).

[alessandrozucca]

To me dig.As sounds nicer than dig.Cast

Or you could use dig.Bind(...) same name as the one used by go-cloud/wire ?

[alessandrozucca]

If this solution is implemented in combination with the one suggested in #181

It will make the following code shorter

type FooParams struct {
	dig.In
	Foo *Foo `name:"foo"`
}
type FooResult struct {
	dig.Out
	Fooer Fooer `name:"foo"`
}
func NewFooer(p FooParams) FooResult {
	return FooResult{
		Fooer: p.Foo,
	}
}

by using

c.Provide(NewFoo, dig.As(Fooer), dig.Name("foo"))

[abhinav]

dig.As(new(Fooer)) but yeah, agreed. We'll explore adding this probably in
a few weeks depending on priorities.

Until then, we suggest continuing to use the explicit func-based cast --
unless you'd like to take a stab at implementing this.

[glibsm]

Going back to one of the original comments:

which is basically making us declare that Foo implements Fooer

Yes, it's true that in Go interfaces are implicit.

However, in the case of a dependency injection container it's a good thing that you have to declare who implements what since there can never be an ambiguity.

Consider the following example:

type A struct {}
func (a A) String() { } // implements fmt.Stringer

type B struct {}
func (b B) String() { } // implements fmt.Stringer

// fx.Provide(NewA, NewB)...
func New(s fmt.Stringer) {} // constructor requiring a fmt.Stringer

In the scenario above, there is an ambiguity. Both objects implement a stringer (it's easy for the container to check that). However, which object is to be returned in that case?

An error would have to be thrown in this case about too may stringers in the container, which is not desired since those two objects should be able to coexist just fine.

[alessandrozucca]

@glibsm yeah, @abhinav already clarified that point in his response #197 (comment)

I'll update the title of the issue.

[rssathe]

@abhinav updates on this?

[abhinav]

Hey @rssathe. I think we have a design we agree upon: dig.As(new(Fooer)) as
a ProvideOption (CC @glibsm). Unfortunately, we don't have the bandwidth to
implement this feature at this time, and it hasn't been a priority because the
manual casting process suffices for our needs for now.

[glibsm]

@abhinav dig.As sounds good to me.

Perhaps also as: tag for dig.Out? Otherwise I don't see an easy way that Fx can consume dig.As. How would this look in Fx world?

[abhinav]

The as: tag might be problematic because we'll be string matching on types
names and packages.

For Fx, now that we have fx.Annotated, maybe it can be a simple mapping
from an fx.Annotated field to a Dig option?

fx.Provide(fx.Annotated{
    Target: NewFoo,
    As: new(Bar),
})

[glibsm]

Ah, that's right. The fx.Annotated wrapper should provide a good solution to this.

[nikkomiu]

Would it be possible to either:

• Change the signature of the Provide to take in ...interface{} as a "second" param where you could specify zero or more interfaces that map to that single struct? This would keep the Provide method backwards compatible.
• Add a secondary function like ProvideNamed that takes the struct as the first argument and the interface it maps to as a second argument? (This would correlate to more of a .NET Core type container injection system)

[glibsm]

Change the signature of the Provide to take in ...interface{}

That is not an option for two reasons:

1. It's an API breaking change, which would require a dig 2.0 version. We are very careful with following the semver practices
2. It would get in the way of all other usages that don't require a cast. Lest say in 5% of the cases, a cast is required (as far as I can tell, it's pretty rare). Any other dig usage would now incur an additional parameter.

Add a secondary function like ProvideNamed

There is a very good post by Dave Cheney on this topic: https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis

Essentially, we don't want to redefine a new method any time some option is introduce (like casting to another interface). We intentionally left room in the API signature of Provide to allow us to introduce new options and features without API breaking changes.

[nikkomiu]

The first option wouldn't be a breaking change because it allows zero or more parameters to be passed into the function. Not one or more. So you also wouldn't be required to pass it into the function.

https://golang.org/ref/spec#Passing_arguments_to_..._parameters

[glibsm]

The first option wouldn't be a breaking change because it allows zero or more parameters to be passed into the function. Not one or more. So you also wouldn't be required to pass it into the function.

I'm not sure I follow.

Provide already defines one set of variadic arguments. You can't have two variadic arguments.
func (c *Container) Provide(constructor interface{}, opts ...ProvideOption) error
https://godoc.org/go.uber.org/dig#Container.Provide

Please illustrate through a code sample what you are suggesting and it's affect on the API.

[nikkomiu]

Ah, I didn't see that there was already a ...ProvideOption on there. That wouldn't have worked anyway 😞...at least not very nicely.

Would it be possible to then add to the ProvideOption interface to allow for interface mapping?

[glibsm]

Would it be possible to then add to the ProvideOption interface to allow for interface mapping?

Yep. dig.As ProvideOption is the currently agreed on way forward.

See the discussion earlier in this issue #197 (comment)

[phamtai97]

Hi all,
Has this feature been released yet? If not, what is the current solution?

[un000]

Hi all,
Has this feature been released yet? If not, what is the current solution?

Manually constructing an object with a lambda.

[zenthangplus]

Hi all, any update?

[toukoubun]

Same problem, and here is my solution.

Different from google/wire, dig can't bind interface with specific value type. But dig can deal with interface and interface
So, we can just write a bind function that receives the value and returns the interface

// receives value and returns interface
func BindFooer(f *Foo) Fooer {
	return f
}

di.Provide(NewFoo)
di.Provide(BindFooer)

di.Invoke(func(f Fooer) {
		fmt.Printf("f: %+v", f)
})

Of course, I know, writing the bind function every time is too much trouble, so can we bind interface with specific value type simply just like google/wire ? For example:

// code from google/wire
wire.Bind(new(Fooer), new(*Foo))
wire.Bind(new(Barer), new(*Bar))
wire.Bind(new(Bazer), new(*Baz))

The answer is YES, here is the source code of bind() function and useage

// bind Fooer with Foo*
di.Provide(bind(new(Fooer), new(Foo)))
// bind Fooer with Foo
di.Provide(bind(new(Fooer), Foo{}))
// if you created Fooer already
var fooer Fooer
di.Provide(bind(&fooer, Foo{}))


func bind(interfaceValue interface{}, structValue interface{}) interface{} {
	interfaceType := reflect.TypeOf(interfaceValue)
	if interfaceType.Kind() == reflect.Ptr {
		interfaceType = interfaceType.Elem()
	}
	if interfaceType.Kind() != reflect.Interface {
		panic("the type of parameter 'interfaceValue' should be interface")
	}

	in := []reflect.Type{reflect.TypeOf(structValue)}
	out := []reflect.Type{interfaceType}
	funcType := reflect.FuncOf(in, out, false)

	return reflect.MakeFunc(funcType, func(args []reflect.Value) (results []reflect.Value) {
		return args
	}).Interface()
}

It works fine for me, good luck

[umi0410]

Binding also works for me. Thank you.

[sywhang]

#293 added dig.As option. We'll try to release this shortly.