Previously, goose would ignore declarations in the //+build gooseinject
files that were not injectors. This meant that if you wanted to write
application-specific providers, you would need to place them in a
separate file, away from the goose injectors. This means that a typical
application would have three handwritten files: one for the abstract
business logic, one for the platform-specific providers, one for the
platform-specific injector declarations.
This change allows the two platform-specific files to be merged into
one: the //+build gooseinject file. goose will now copy these
declarations out to goose_gen.go. This requires a bit of hackery, since
the generated file may have different identifiers for the imported
packages, so goose will do some light AST rewriting to address these
cases.
(Historical note: this was the first change made externally, so also in
here are the copyright headers and other housekeeping changes.)
Reviewed-by: Tuo Shan <shantuo@google.com>
Reviewed-by: kokoro <noreply+kokoro@google.com>
To avoid making this CL too large, I did not migrate the existing goose
comments through the repository. This will be addressed in a subsequent
CL.
Reviewed-by: Tuo Shan <shantuo@google.com>
An interface binding instructs goose that a concrete type should be used
to satisfy a dependency on an interface type. goose could determine this
implicitly, but having an explicit directive makes the provider author's
intent clear and allows different concrete types to satisfy different
smaller interfaces.
Reviewed-by: Tuo Shan <shantuo@google.com>
Names are inferred from types most of the time, but have a fallback for
a non-named type. Names are now also disambiguated from symbols in the
same scope.
Reviewed-by: Tuo Shan <shantuo@google.com>
Reviewed-by: Herbie Ong <herbie@google.com>
Single-element provider sets are frequently useful enough to warrant
being a default. Larger groupings within a package are less frequent.
Reviewed-by: Herbie Ong <herbie@google.com>
Reviewed-by: Tuo Shan <shantuo@google.com>
