sarulabs/dingo

Generated dependency injection containers in go (golang)

dingo's Issues

Link to the constructor in GetService() method comment

Sometimes when I watch at some GetService() method generated by container I want to check the constructor which used by this method. Not the build func from definition, but the constructor of the Service itself.

Would be nice to have comment for the GetService() which will contain link to the constructor of the service.
Something like:
// This method uses package.NewService method

What do you think about this?

Add Put method, which will replace key in map, but not value by pointer

Sarulabs, i really grateful for adding the Fill method to container. I found out how does it works. But it is not the thing i need.

I have the test function, where i want to get some destination service with all dependencies resolved. But i don't need real repository to be resolved as dependency of userFetcher. What i do want is to place userRepoMock to container before resolving my service. So when later i will get my destination service, it will depend on Mock service instead of real one.

func test() error {
	container, err := dic.NewContainer(dingo.App)
	if err != nil {
		return err
	}

	userRepoMock := user.RepoMock{}

	if err := container.Fill("user-repository", &userRepoMock); err != nil {
		return err
	}

	fetcher := container.GetUserFetcher()
        // here fetcher depend on mock, not on real userRepository
	fmt.Println(fetcher)

	return nil
}

Is that possible to add some kind of Put method, which will replace existing object?

I see 2 possible ways to achieve that:

1. Add to definition field like: Redefinable. If that field is true, type safe Put method will be generated for that definition.
2. Add generic Put method, which will check for the same type or for the same interface. Checking is optional, but it will make errors more verbose.

Very poor docs

very poor docs that could be fixed so new users like me can use it with ease

Package incapsulation with Dingo

I have some package, where interface is public, but the structure, that implements that interface is private.

When i try to declare definition function with return type of public interface, but return pointer to private structure, that implement interface - getting error:

could not scan definitions: could not scan definition <definition-name>: object type is <Interface> but <pointer to structure> is used is Close

To solve that i must return the same type, that was declared in return type of definition of function which adds some artificial limitations

What about functional tests?

In https://github.com/sarulabs/di there is a great method Fill, which can be used to put object, for example mock by key. It is very useful, when it comes to functional testing. Do this package has any functions to make the same thing?

It looks like that If the Definition returns an interface type, each type, that implements that interface could safely replace existing in the container object.

Error on attempt to cast function with `ed25519.PrivateKey` argument

Hello,

Thank you very much for this container, it helps a lot with decreasing client's code amount.

I faced with the problem of using ed25519.PrivateKey type (wrapper for []byte type) within Builder function.
My Builder function looks like:

func(config *infra.Config) (ed25519.PrivateKey, error)

When I'm trying to build container, I get error:

could not cast build function to func(*infra.Config) ([]uint8, error)

Possible workaround: change argument type from ed25519.PrivateKey to []byte.

could not load definition with type *dingo.Def

After updating dingo binary to v3.1.0 getting error on code generation.

dingo -src="def" -dest="def/gen"
[KO] An error occurred while running the generated compiler:
could not load definition with type *dingo.Def (allowed types: dingo.Def, *dingo.Def, []dingo.Def, []*dingo.Def, func() dingo.Def, func() *dingo.Def, func() []dingo.Def, func() []*dingo.Def)

On version 2.0.0 generator was working OK

Automatic DI?

Hi! I saw this in a medium post and realised that you did a nicer version of what I did in http://github.com/j7mbo/Goij, in utilising the AST for strings -> structs.

The best thing for me was that I used the New convention to automatically initialise structs, recursively. Allow mappings from interfaces to concretes. But the rest basically can be fully automatic.

Would you consider allowing Dingo to become fully automatic, so no configuration needed except for when explicitness is required (interface -> impl)? Any chance of a collaboration on that?

Missing functionality

Hello,

Currently missing in sarulabs/dingo :

By default the objects are shared that means what they stored as singletons in the Container. You will retrieve the exact same object every time you call the Get method on the same Container. The Build function will only be called once. In case when you don't want the objects to be shared set the Unshared property of object definition to true.

dingo service definitions do not have an Unshared property:

package dingo

// Def is the structure containing a service definition.
type Def struct {
	Name  string
	Scope string
	// NotForAutoFill should be set to true if you
	// do not want to use this service automatically
	// as a dependency in other services.
	NotForAutoFill bool
	// Build defines the service constructor. It can be either:
	// - a pointer to a structure: (*MyStruct)(nil)
	// - a factory function: func(any, any, ...) (any, error)
	Build interface{}
	// Params are used to assist the service constructor.
	Params Params
	// Close should be a function: func(any) error.
	// With any being the type of the service.
	Close interface{}
}

Any plans on adding this?

Move dic.C into another file inside the output that survives between generations

It would be nice to be able to change dic.C inside the package without changes being clobbered when a new container is generated

Param should be Interface, realization given

It looks like it's correct behaviour, when concrete realization passed as parameter to method, which waits for interface that realization implements.

I think it could be fixed with adding reflect.TypeOf().Implements() check.
What do you think?

Add ability to use slice of services in Params field

Hello there.
It would be really nice to be able to use in Params not map, but slice.
If Params field used for services - map keys are just indexes. The slice can be used. It is pretty annoying to edit all indexes if some param has been added to the middle of the params list.
I believe it is done in that way to use Params for different cases, but if you can add another field like SliceParams - it would be fantastic.

Tweaking the output package name would be useful

Could you please add package name as parameter to GenerateContainer func ? Like:

func GenerateContainer(provider Provider, outputDirectory, packageName string) error

or

func GenerateContainer(provider Provider, packageName, outputDirectory string) error