So:
$ cat mypackage.go
package mypackage
import "something/something/foo"
func MyFunction() {
some code
some code
some code
foo.Bar(make(chan foo.Baz), make(chan foo.Foobar))
}
Is the code I would really like to write.
foo has build constraints. As you can see, my code doesn't, it's the exact
thing you recommended: the common code is in mypackage.go, the platform
specific code is in foo (which I don't control, it isn't my code, so I
can't change it). How to unit test MyFunction to verify that it uses
foo.Bar correctly?
Normally, I would just pass foo.Bar in argument to the function or do
something like var fooBar = foo.Bar so I can replace it in unit tests. But
in the case of a foo package that has platform build constraints, I don't
see how it's possible without creating a wrapper.
On Wednesday, January 5, 2022 at 10:20:47 AM UTC Jan Mercl wrote:
> On Wed, Jan 5, 2022 at 11:09 AM Brieuc Jeunhomme <bjeun...@gmail.com>
> wrote:
>
> > But here ,since under non-windows platforms, I can't import the package,
> it means I have to define wrappers for everything I use: types, constants,
> functions.
>
> I don't get it. Put the common code in a file/in files with no build
> constraints and the target specific bits in files with build
> constraints for the target. What wrappers are needed and why?
>
> Package level declarations are visible in all files within a package -
> meaning they have package scope. The sole exception is the package
> qualifier explicitly or implicitly declared by an import statement.
> Such identifier has file scope.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/74eed2b8-9a6a-4ad1-a30a-9ceca71e5bc8n%40googlegroups.com.
