Are the following assertions about Go packages accurate?

Are the following assertions about Go packages accurate?

1. import "package_name" imports all files from the directory called package_name assuming is found in $GOPATH, a variable that holds the users go directory, or in the standard go installation directory tree.

2. files within the package_name directory will usually state package package_name. But they are not required to. In fact, import "package_name", would also import a file including the line package foo if the file was found in the imported package_name directory.

3. All functions that are Capitalized will be accessed through the name given in the package package_name declaration--for instance:

package_name.Function_in_file_that_declares_package_name or other_than_package_name.Function_in_file_that_declares_other_than_package_name

4. User defined packages are command-line go install-ed from the within the package directory. However, go will refuse to install a directory named identically to its builtin package directories. For instance you cannot install a strings directory since go already has a strings directory for the builtin package "strings." However, the user can append functions to the strings package without altering the builtin strings folder, by creating a my_strings directory and the placing a file that states package strings within it. Now, import my_strings will load the extra user-defined strings functions accessed with strings.Function_name.

In summary, the import keyword is used to load files from a given directory. And the keyword package creates a namespace to access Capitalized functions from outside that file.

Am I understanding all of the above correctly?

1. The argument of "import" is an import_path, not a package name. It makes exported entities from a package found in $GOPATH/src/import_path available in the file scope where the "import" clause appears.

2. All *.go files, except *_test.go files and files with // +build ignore, in a single directory must say the same name in the package name clause or the go build system will reject it.

3. Not capitalized, but belonging to the Unicode category Lu. Not functions but any TLD entity.

4. No, you can go-install any package from any directory using its import path. Yes, packages from the stdlib have priority and cannot be "overriden". However, you can effectively "replace" a stdlib package using eg. import strings "github.com/foo/mystrings". However, the effect is local/file only.

In summary, no, import is used to make entities from other packages available in the file scope. The keyword "package" creates no namespace. The effect of "import" is file-scoped, see the preceding sentence and usually the imported entities are referred to by qualified names. That qualifier is a sort of namespace, but note that not the "exporter" (package foo) controls that. Instead the control is at the "importer" side: import whatever_local_name "whatever_import_path". The default qualifier is the basename of the import path, though.

"Do we all agree?"

Not at all.

Even if it sounds harsh: Almost all assumptions are completely wrong.

Take a look at http://golang.org/doc/effective_go.html#package-names and http://golang.org/ref/spec#Packages and do not think of import as the Go equivalent of C's include.

Go's packages are more like precompiled libraries and an import "some/path/foo" is more like linking in foo.a (but also makes exported entities available under - normaly - foo.SomethingExported.

Now have a look at http://golang.org/doc/code.html and it should become clear what packages are and how they are used.