我正在开发一个go包,它有点复杂,因此我想把源代码组织到多个目录中。
然而,我不希望包的用户使用太长的导入,不管怎样,包的内部结构不是他们关心的。
因此,我的包结构看起来是这样的:
subDir1
subSubDir1
subSubDir2
subDir2
subSubDir3
......等等。它们都有它们的导出调用。
我希望避免我的用户必须导入
import (
"mypackage/subDir1"
"mypackage/subDir1/subSubDir2"
)
...等等。
我只是想,如果他们想使用我的包中导出的函数,他们应该通过简单地导入mypackage
来访问所有这些函数。
我试着在所有的.go
文件中声明package mypackage
,这样,我的源文件在不同的目录中,但是包声明是相同的。
在这个例子中,我遇到的问题是我无法从同一个包中导入多个目录。
./src1.go:6:15: error: redefinition of ‘mypackage’
"mypackage/mysubdir1"
^
./src1.go:4:10: note: previous definition of ‘mypackage’ was here
"mypackage"
^
./src1.go:5:15: error: redefinition of ‘mypackage’
"mypackage/mysubdir2"
^
./src1.go:4:10: note: previous definition of ‘mypackage’ was here
"mypackage"
^
这可能吗?
3条答案
按热度按时间0s0u357o1#
在任何情况下都不应该这样做,因为语言规范允许编译器实现拒绝这样的构造。封装子句:
一组共享相同PackageName的文件构成包的实现。实现可能要求包的所有源文件位于同一目录中。
相反,“结构化”你的文件名模仿文件夹结构;例如,代替
您可以简单地用途:
此外,如果您的包非常大,甚至需要多个文件夹来“托管”包实现的文件,那么您应该真正考虑不要将其作为单个包来实现,而是将其分解为多个包。
还请注意,Go 1.5引入了internal packages。如果在包文件夹中创建一个特殊的
internal
子文件夹,则可以在其中创建任意数量的子包(即使使用多个级别)。您的包将能够导入和使用它们(或者更准确地说,所有以你的包文件夹为根目录的包),但是外面的其他人不能这样做,这将是一个编译时错误。例如,您可以创建一个
foo
包,有一个foo/foo.go
文件,和foo/internal/bar
包。foo
将能够导入foo/internal/bar
,但boo
不能。此外,foo/baz
也将能够导入和使用foo/internal/bar
,因为它的根目录是foo/
。所以你可以使用内部包把你的大包分解成更小的包,有效地把你的源文件分组到多个文件夹中。你唯一需要注意的是把你的包想要导出的所有东西都放进包里,而不是放进内部包里(因为那些东西从“外部”是不可导入/不可见的)。
qv7cva1a2#
在你的包源代码中,你必须通过 renamed imports 来区分你的源目录。你可以在你的所有源文件中声明相同的
package mypackage
(即使它们在不同的目录中)。但是,在导入它们时,您应该为这些目录给予一个单独的名称。在您的源
src1.go
中,按以下方式导入其他目录:您将能够访问在“mypackage”中定义为
mypackage.AnyThing()
的API,以及在mySubDir
中定义为submodule1.AnyThing()
的API。外部世界(即包的用户)将看到
myPackage.AnyThing()
中的所有导出实体。避免命名空间冲突,并使用更好的欠稳定、直观的命名,如示例所示。
7vhp5slm3#
是的,这是可以做到的,没有任何问题,只需手动调用Go编译器,而不是通过
go
工具。但最好的建议是:不要这样做。这很难看,而且不必要地复杂。只要正确地设计你的 Package 就行了。
补遗(因为这个回答的真实的意图有时似乎会迷失,也许是因为讽刺太微妙了):不要这样做!!这是一个难以置信的愚蠢的想法!停止对抗工具!如果你这样做,每个人都会理所当然地恨你!没有人会理解你的代码或能够编译它!仅仅因为一些事情在理论上是可行的,并不意味着这是一个明智的想法在任何方面。甚至不是为了“学习的目的”!你甚至可能不。我不知道如何手动调用Go语言编译器,如果你弄清楚了,那将是一个很大的难题。