包装声明的目的是什么？ [英] What is the purpose of the package declaration?

问题描述

每个Go文件都以包< something> 开始。

据我了解 - 可能是我缺少一些信息的地方 - < something> 只有两个可能的值：它所在目录的名称*或主。如果它是 main ，则该目录中的所有其他文件也只能有 main 。如果是别的东西，这个项目是不一致/违反约定的。

现在，如果它是目录的名称，这是多余的，因为相同的信息，如果它是 main ，这是没用的，因为就我而言可以看到没有办法告诉 go build 到请建立所有 main 包。
$ b

^{*因为，换句话说，一个目录是一个包。}

解决方案

包的名称不必与目录名称一致。可以在目录 xyz / go-foobar 中包含包foobar 。在这种情况下， xyz / go-foobar 会成为导入路径，但您用于质量的包名称标识符（函数，类型等）将是 foobar 。

下面是一个更加具体的例子：我创建了一个测试包 http://godoc.org/github.com/dmitris/go- foob​​ar （来源 https://github.com/dmitris/go-foob ） - 您可以从文档页面看到，导入路径是github.com/dmitris/go-foobar，但包名称是 foobar ，所以您可以致电它提供的函数为 foobar.Demo（）（不是 go-foobar.Demo（））。

一个类似的实际例子 - NSQ Messaging平台的导入路径是github.com/nsqio/go-nsq，而软件包名称是nsq ： http://godoc.org/github.com/nsqio/go-nsq。但是，为了用户友好和简单起见，标准和推荐的做法是尽可能保持导入路径的最后部分和包名称相同。

package main 并非无用 - 它告诉Go编译器创建一个可执行文件，而不是一个.a库文件（使用 go install 或 go get ; go build 放弃编译结果）。这个可执行文件的名字是在放置 package main 文件或文件的目录名称之后命名的。再次举一个具体的例子 - 我做了一个测试程序 https://github.com/dmitris/go-foobar -client ，你用去安装它，去获取github.com/dmitris/go-foobar-client ，你应该得到一个 go- foob​​ar-client 可执行文件放置在$ GOPATH / bin目录中。它来自放置包main 文件的目录名称，Go编译器从中获取可执行文件的名称。包含 main（）函数的 .go 文件的文件名并不重要 - 在上例中，我们可以将 main.go 重命名为 client.go 或其他内容，但只要包含的目录名称为 go-foobar-client ，这就是结果可执行文件的命名方式。

去包裹，我推荐戴维切尼的文章建立一个Go项目的五个建议 http://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project 。

Every Go file starts with package <something>.

As far as I understand - and this is probably where I am missing some information - there are only two possible values for <something>: The name of the directory it is in*, or main. If it is main, all other files in that directory can only have main, too. If it is something else, the project is inconsistent/violating convention.

Now if it is the name of the directory, it's redundant, because the same information is, well, in the name of the directory.

If it is main, it's kind of useless, because as far as I can see there is no way to tell go build to "please build all main packages".

^{* Because, in other words, one directory is one package.}

解决方案

The name of the package does not have to coincide with the directory name. It is possible to have package foobar in the directory xyz/go-foobar. In this case, xyz/go-foobar becomes an import path, but the package name that you use to quality the identifiers (functions, types etc.) would be foobar.

Here's an example to make it more concrete: I created a test package http://godoc.org/github.com/dmitris/go-foobar (source in https://github.com/dmitris/go-foobar) - you can see from the documentation page, that the import path is "github.com/dmitris/go-foobar" but the package name is foobar, so you would call the function it provides as foobar.Demo() (not go-foobar.Demo()).

A similar real-life example - the import path for the NSQ Messaging platform is "github.com/nsqio/go-nsq" while the package name is "nsq": http://godoc.org/github.com/nsqio/go-nsq. However, for the sake of user-friendliness and simplicity, the standard and recommended practice is to keep the last portions of the import path and the package name being the same whenever possible.

package main is not useless - it tells the Go compiler to create an executable as opposed to a .a library file (with go install or go get; go build discards the compilation result). The executable is named after the directory name in which the package main file or files are placed. Again a concrete example - I made a test program https://github.com/dmitris/go-foobar-client, you install it with go get github.com/dmitris/go-foobar-client and you should get a go-foobar-client executable placed in your $GOPATH/bin directory. It is from the the directory name where the package main file is placed that the Go compiler takes the name of the executable from. The filename of the .go file that contains the main() function is not important - in the example above, we can rename main.go to client.go or something else, but as long as the enclosing directory is called go-foobar-client, that's how the resulting executable will be named.

For an additional accessible and practically oriented reading about Go packages, I recommend Dave Cheney's article "Five suggestions for setting up a Go project" http://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project.

这篇关于包装声明的目的是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！