This repository has been archived by the owner on Mar 22, 2019. It is now read-only.
Added the ability to override non-zero values #15
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please note that this patch does not break any of the existing functionalities
or guarantees of the package; it is only a collection of features that I would
have liked the package to have.
Previously, if some subtree of an object that was to be populated
was not zero/nil, we would terminate the population of that subtree
then and there. However this makes the package hard to use for very
targeted dependencies that only occur at the bottom of the dependency
tree (e.g: a network client or database layer).
With this patch, the injection does move downwards and populate the
fields that it can (see inject_test.go::TestNonEmptyInterfaceTraversal for example).
Furthermore, we can now have constructors populate our structs with
default values, that will then be overridden by the injection
mechanism if the tag
inject:"override"
is present on the field.This means that we can now use sane defaults when creating our objects
that we can inject mocks for during unit tests.
The last feature that I was looking for was the traversal of non-nil
interfaces. For instance:
This is useful in bigger projects when you have many subcomponents that
use an *http.Client or sub-interface of that, and need to all have that
client mocked during unit tests.